Re: [Freedos-devel] 4dos and real mode JWasm crash under non-KVM QEMU
Hi, On Sun, Sep 29, 2024 at 7:12 AM Bernd Böckmann via Freedos-devel wrote: > > As we are revisiting some issues reported, let me add another, rather > strange one. Some programs crash under non-KVM QEMU, while working on > all other configurations I tested (real hardware, 86box, DosBox etc.) > > This is independent from the used DOS kernel (tested FreeDOS and EDR) > > https://github.com/SvarDOS/core/issues/120 Obviously real mode is not their top priority. Did you try good ol' 4DOS 7.50 from 2004? Because 4DOS 8.00 did change a lot. I would naively suspect a timing issue since JWasmR presumably doesn't do anything else system-specific. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] BREXX: a REXX implementation with interrupts (when on 16 bits)
Hi,
On Sat, Sep 14, 2024 at 1:36 AM Paul Dufresne via Freedos-devel
wrote:
>
> It had come to my mind that it could be great, to implement interrupts calls
> in a REXX implementation...
>
> apparently someone did it already:
> https://github.com/vlachoudis/brexx/
>
> You can see some in:
> https://github.com/vlachoudis/brexx/blob/master/lib/conio.r
> or in:
> https://github.com/vlachoudis/brexx/blob/master/lib/dos.r
He doesn't even mirror the old DOS builds anymore, AFAIK. (You used to
be able to get some from gwdg.de via FTP, but modern browsers shun
that old protocol nowadays.)
I never tried the INTR and PORT stuff. Most of my interest was in
portability of some simple scripts.
The Brexx 1.3 DOS release from 1997 was on Simtel (and mirrors).
RX.EXE was "16-bit" but still compiled with BC++ 3.1 for 386+ cpus and
had Paradox database support (whatever that means). It's not as
compliant as later versions, so it's not quite as good, but I tried
using it a bit anyways. I still have a .ZIP around here. I rebuilt it
with TC++ 1.01 and NASM, which gave about 500 kb free RAM ("say
storage()"), but the stack depth is too limited to do piping, e.g.
"dir )stack" and "stack> sort" might work, but hundreds of lines
won't.
There was also a rarer Brexx 1.3.3 DOS build (without Paradox) but not
hugely improved.
Brexx 2.1.0 (from 2003) was much better, called "rexx16.exe" but still
386+ and built via (non-standard) BC++ 3.1. Again, I got this to
rebuild with TC++ 1.01 and NASM. I honestly don't know if the overhead
for this one is worse or better than 1.3. So I really wouldn't
recommend the older one, but for comparison it does exist. (Anyways, I
ported 1.3 to 8086 first before porting 2.1.0.)
I also have a DJGPP build of Brexx 2.1.9 from 2011. (He also had an
Android port I barely used back in 2012. The 1.3 release has several
other binaries, too.)
I don't know whether he has relicensed his old code to be fully GPL or
not. (It used to be "non-commercial only".)
Eventually I want to mirror all of these (DOS-related) REXX things to
my Google Drive. But I haven't finished updating the 8086 patches.
(They seem to work fine, just not quite perfect. For instance, Sed is
not strictly needed to build at all. It was just for TASM to NASM
conversion.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] a unit converter program in REXX... probably not working under DOS yet
Hi, On Fri, Sep 13, 2024 at 10:01 PM Paul Dufresne via Freedos-devel wrote: > > It began when I did read: > https://bttr-software.de/forum/board_entry.php?id=22023 > > Anyway, I wrote a small program to convert units ... it is using a bit > sophisticated stuff... making it sadly probably not usable for DOS as is. > > -- The following 2 calls are for loading regutil library > -- it is needed only for regStemDoOver > -- to work, program must be called with regina rather than rexx > -- Because of this, it is believe the program cannot run under DOS > call RxFuncAdd 'sysloadfuncs', 'regutil', 'sysloadfuncs' > call sysloadfuncs I did not run (test) your code, but keep in mind The main thing to remember is that REXX has different dialects. You can even check at runtime and branch accordingly based upon host OS or language version. * Mike Cowlishaw's _The Rexx Language_ (2nd edition, 1990) is commonly called TRL2, aka version 4. * ANSI standard REXX from 1996, e.g. Regina, calls itself version 5. * OORexx calls itself version 6 (actually, 6.03, last I checked). So there are some differences, esp. with regards to how external stacks are handled or whether to use ADDRESS SYSTEM WITH or other features. Just because code works in one interpreter doesn't mean it will work (at all) on others unless you are very careful and test accordingly and limit non-standard extensions. That may not matter for local code, but for anything public or "portable", you have to be more careful. For instance, Ada-like single-line comments -- are not standard and are only supported by Regina (IIRC). N.B. Howard Fosdick's 2005 REXX book is now a free download and quite exhaustive (highly recommended): * the https://rexxinfo.org/tutorials/index_tutorials.html You may also wish to read up on other REXX pitfalls: * http://web.archive.org/web/20210314104341/http://www.edm2.com/index.php/Common_REXX_Pitfalls "do over" is only in OORexx, is that right? I haven't really messed with that one much, but normal practice seems to be to manually put the size of the stem (array) in stem.0 and loop over that, e.g. "do i=1 to stem.0; say stem.i; end". I'm far from super experienced with REXX, but I've dabbled with it a bit, off and on. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Converting WordStar to HTML
Hi,
On Fri, Aug 16, 2024 at 9:16 AM Jim Hall via Freedos-devel
wrote:
>
> Jim Hall wrote:
> > >
> > > I published an article last week on Both.org about how to convert
> > > WordStar files to HTML.
>
> I've added SAMPLE.WS and a few others in a 'wordstar' folder.
I'm mildly curious about your choice of C dialect.
Although C++ is beyond me (in most ways), so I know very little there.
(Like many languages, it has a long history and several dialects. I
barely wrote a very simple C++98 program with DJGPP a few months ago.)
You seem to use ANSI C, or C89/C90 (as it's sometimes called).
I like your BOOL typedef (a clever solution I've also used). I also am
still sympathetic to C89 (and DOS compilers).
Having said that, "bool" is also a feature of (semi-modern) C++ and
C99. (Well, OpenWatcom supports "bool" but TurboC++ does not, IIRC.)
So are // line comments. And "for (int i=0;" declarations. (But
"inline" support may be too limited to be useful.)
Your article says you used GCC, which by default (last I checked) is
"-std=gnu17", so it supports "bool" and // as well by default. (Okay,
C++ supports bool by default. C99 needs . Obviously. I'm
mainly testing OW's C++ here, basically implying that these features
also are available in C99.)
Are you trying to strictly stay compatible to C89? Or is it just
habit? Since it works in OpenWatcom (as C++ or C99 with )
and DJGPP, I would personally use such features. (Okay, I wouldn't,
but I *could*. It depends on how many compilers and OSes you want to
target.) In other words, in an abandoned DOS landscape, I'm halfway
seriously suggesting using old C++ as if C99.
Heck, you could make a simple #define, and the line comments could be
trivially converted to C89 style with Sed (or a very simple util).
#if !__cplusplus || defined __TURBOC__
typedef enum {false,true} BOOL;
#else
#define BOOL bool
#endif
sed -e "s,//\(.*\),/*\1*/," wshtml.c99 >wshtml.c89
* (UNCMNTC: uncomment C, it's a 3 kb .C source, public domain)
*
http://cpmarchives.classiccmp.org//cpm/mirrors/cbfalconer.home.att.net/download/uncmntc.zip
See what I mean? You don't strictly have to do without everything. You
have options.
Okay, you barely mentioned GCC: "gcc -o wshtml wshtml.c". Thanks to
GNU Make's built-in rules, you can probably simplify that to just
"make wshtml".
You hardcoded C escape sequences (char literals) as numbers instead:
case 0x09: /* tab */
case 0x0a: /* new line */
case 0x0c: /* page feed */
case 0x0d: /* carr rtn */
But you could just use '\t' '\n' '\f' '\r':
* https://stanislavs.org/helppc/c_escape_sequences.html
I don't know why you use "return 1;" and "return 0;" instead of using
EXIT_SUCCESS and EXIT_FAILURE . (It's ANSI standard, and
IIRC the only DOS compiler who omits it is Pacific C.)
fmt.bold = false; fmt.dblstrike = false; fmt.underline = false;
You can initialize all of those at once:
fmt.bold = fmt.dblstrike = fmt.underline = false;
C99 and C++ also let you put "size_t i;" into the "for (i = 0 ..."
statement -> "for (size_t i = 0; ..."
Oh, even C89 lets you combine these two statements (at the start of a block):
"BYTE low; low = ch & 0x7f;" -> "BYTE low = ch & 0x7f;"
Is "if (len > 0)" even necessary? Will "for (i = 0; i < len ..." even
iterate if loop count is less than 1? It probably?? shouldn't.
You could simplify all of these:
'if (fmt.bold) { fputs("",out); } else { fputs("",out); }'
'fputs(fmt.bold ? "" : "",out);'
You could also combine these two statements:
'pfile = fopen(argv[1],"rb");' "if (pfile==NULL) {" -> 'if
((pfile=fopen(argv[1],"rb"))==NULL) {'
There are some other suggestions, but they are mostly about personal taste?
N.B. I tested most of this with OpenWatcom 1.9 as C++ (under DOS), and
the SAMPLE.WS output matched the C (C89) version's output. (The .EXE
was barely 102 bytes bigger.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Converting WordStar to HTML
You forgot to include "sample.ws" (or any other test suite). On Mon, Aug 12, 2024 at 3:37 PM Jim Hall via Freedos-devel wrote: > > I published an article last week on Both.org about how to convert WordStar > files to HTML. > > Someone asked me if I could share the code from the article in a GitHub repo. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] convert ms-dos code to C#
Hi, On Wed, Jul 31, 2024 at 3:28 PM Jim Hall via Freedos-devel wrote: > > ..I saw "Twilight was a physical collection of illegal software and > games." So I haven't heard about THF because I don't deal in "illegal > software and games." (I think this is what used to be called "warez" - > also mentioned in the link below.) I also saw this link with more > information: > https://twilight-cd.com/ > > >>Twilight was the longest running illegal software series in the > >>Netherlands, with the largest sales market. The collection was released > >>from 1996 to 2004 and blossomed into a huge success and cash cow. Over the > >>years, Twilight has changed from a hobby project by a bunch of computer > >>nerds to a (as it seems) rock-solid underground organization. > >> > >>In eight years, one hundred and eighty discs with “apps and games” > >>were produced, which were sold privately from factory to end user. I'm not that naive, but it seems pointless when Free operating systems like GNU / Linux (and FreeDOS!) already existed. Heck, even shareware is (usually) better than warez. Last I heard, the Netherlands is lax on downloads (but not uploads), so it's not necessarily "illegal" to download things. On a vaguely similar note, I think (communist??) Poland in the '80s also had a lot of "warez" scenes and shared software, probably due to blockades or sanctions or whatever There is also a Wikipedia article: * https://en.wikipedia.org/wiki/Twilight_(warez) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] convert ms-dos code to C#
Hi, On Wed, Jul 31, 2024 at 2:51 PM magic-girl--- via Freedos-devel wrote: > > i'm an autistic girl of 12 years old. I try to convert ancient 16 bit ms-dos > code to modern C#. > However there is not even docs anymore about old ms-dos functions and i don't > have ms-dos specific C knowledge. Try looking at old classic HelpPC (David Jurgens): * https://stanislavs.org/helppc/ or * https://helppc.netcore2k.net/ or * https://www.sac.sk/download/text/helppc21.zip "helppc21.zip HelpPC v2.1 - PC Programmers 1995-01-20" For instance: * https://helppc.netcore2k.net/interrupt/int-21 int 21h INT 21,3C Create file using handle INT 21,3D Open file using handle INT 21,3E Close file using handle INT 21,3F Read file or device using handle INT 21,40 Write file or device using handle INT 21,41 Delete file INT 21,42 Move file pointer using handle * https://helppc.netcore2k.net/c/fread * https://helppc.netcore2k.net/c/-dos-write * https://helppc.netcore2k.net/c/cprintf ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Lua 5.4.7 available for DOS
Hi, On Tue, Jul 23, 2024 at 9:39 PM Alexander Walz via Freedos-devel wrote: > > you will find the DOS version of the latest release of Lua 5.4.7, > a powerful, efficient, lightweight, embeddable scripting language, > and released around one month ago, at: > > https://sourceforge.net/projects/agena/files/Lua%20for%20OS2%20and%20DOS/ > > The ZIP file not only includes the binaries compiled with latest DJGPP, but > also the amended source files. Thank you very much. There have been previous DOS builds, as I'm sure you know. Juan Manuel Guerrero's build of Lua 5.2.2 for DJGPP: * https://www.delorie.com/pub/djgpp/current/v2tk/lua522b.zip LoveDOS (yes, a Lua fork) meant for simple games (with PCX graphics): * http://www.bttr-software.de/forum/board_entry.php?id=16700#p16700 * https://github.com/rxi/lovedos/releases Sadly, I've never messed around much with Lua. I spent more time with Sed, AWK, and REXX (and traditional languages like Pascal). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Missing sources
Hi, On Fri, Jul 12, 2024 at 7:44 PM Jerome Shidel via Freedos-devel wrote: > > The first remaining “missing sources” package is CPIDOS. It is part of BASE > and is always installed. Basically, it just contains some binary CPX files > with codepage font’s in them along with some documentation. This should > probably have a SOURCES directory that contains the actual fonts along with > the script or tools needed to create those CPX binaries. The package is > listed as GPLv2 and without those files I don’t see an easy way to modify the > CPX files. I think this needs resolved. I believe they are actually compressed with UPX. While UPX itself is GPL, I think the "stubs" are free from any restrictions (if you don't modify them). Therefore, I don't think we need to include any actual "code" with these fonts as sources. If someone wants to modify them, IIRC you just "ren *.cpx *.com && upx -d *.com" and continue from there. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New libfp-0.0!
Hi,
On Mon, Jul 1, 2024 at 11:07 PM Jim Hall via Freedos-devel
wrote:
>
> I've been having sporadic problems today when trying to access Ibiblio
> via the web. I'm not sure if that's my end ("The connection has timed
> out") or their end. For example, I was able to download the T2407 test
> release this morning, but when I went back to Ibiblio later in the day
> to download something else, I couldn't access the website. Has anyone
> else had issues connecting to Ibiblio today?
Yes, I had trouble with iBiblio too (about two hours ago). Strange
because they are usually pretty reliable.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Runtime
Hi,
(Sorry for being late to this discussion, I'm a bit backlogged.)
On Thu, May 2, 2024 at 7:05 PM Jim Hall via Freedos-devel
wrote:
>
> On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
> wrote:
> [..]
> > *Runtime*
> >
> > Jim's version is a small C program, 120 lines, using catgets
> > for messages which can be translated in different languages.
> > The binary is a 22kB EXE (31kB without UPX). There were text
> > files with EN, RU, DE, HU and LV translations, I believe?
The latest version of Jim's on iBiblio appears to be 2.1d from 2005.
It has a "Borland TC makefile" using "-mm" (medium model? why?) and
-DNDEBUG in addition to linking to Kitten. The .EXE is 26 kb,
presumably UPX'd, and I'm guessing it uses floating point emulation
(which is unlikely to help much and is extra bloat that is totally
unnecessary for any Pentium or newer FPU-having cpus).
Not trying to nitpick (I've also been looking at old code of mine from
2013 called TIMEIT.C), but just FYI
1). his code isn't ANSI C89
= why include dos.h or process.h ? it says for exec() but uses
spawnvp(), I would normally prefer system()
= does that save memory? are we intentionally trying to avoid shelling
out to %COMSPEC% except for .BATs or built-ins?
= CLK_TCK is not ANSI (old 1988 POSIX???) and not at all preferred,
use CLOCKS_PER_SEC
2). Borland does use 64 kb of heap by default in the smaller data
models. To avoid that (and save a bit of memory, esp. since we're
shelling out), put "extern unsigned _heaplen = 1024;" and "extern
unsigned _stklen = 8192;" in your source. Try shelling out "mem /c" to
see the difference. (Maybe this is why he randomly chose "-mm" Medium
model?? Unnecessary, I'd just use Small.)
3). You really don't need printf() at all here (okay, maybe only for
Kitten ??). It doesn't matter as much for Turbo C, but even for
OpenWatcom it's like 6 kb. If you don't need floating point (see
below), you can make do with a simple "writelong()" routine and save
space. (Yes, I wrote such a routine, if you need it.) FYI, clock_t is
usually a typedef to a "long" integer.
4). In my program, I included both clock() and difftime(). My memory
(and notes) indicate that clock() was for integer times. You know, for
most simple uses, a round number of seconds elapsed is good enough
(and faster / smaller, no bloated and slow emulation lib or expensive
FPU needed). How often does 11 secs. versus 11.5 seconds matter?? A
naive Google search shows people advising to cast it to double! But
that defeats the whole point, IMHO. All the compilers I checked (about
a dozen) all have an integer value for CLOCKS_PER_SEC ... except Turbo
C! There it's 18.2 (for no good reason). Quick: undefine that and
redefine it to 18, that's good enough, IMHO. Or just use OpenWatcom.
> > My version is a small ASM program, made with NASM. It has
> > a main file, circa 450 lines, and a language include file,
> > circa 150 lines, which at the moment contains EN, DE, NL,
> > PT, ES, FR, TR, IT, PL and RU messages :-)
The 2012 version on iBiblio pointed to by Fritz was my unofficial hack
with EO (Esperanto) support.
Checking the latest "2024" version hosted online, it only adds HU but
omits EO. (That's fine if no one cares, but it feels like a
regression.)
> > As a task left as an exercise for the user, one could port
> > the C version to Tom's small KITTEN alternative to CATGETS.
2.1d from 2005 uses Kitten. The MAKEFILE.TC says this:
LDLIBS=kitten-b\kitten.obj
> > My preferred option would be to add HU and LV translations
> > to my small RUNTIME and use that instead of the big one ;-)
Most of that bloat can be removed in one of two ways:
1). use TC's -f87 or WCL's -fpi87 (mandatory hardware floating point
usage, no emulation)
2). use TC's -f- (avoid floating point entirely) only with
integer-friendly clock() and printf("%ld") code
> I wrote the Runtime program, so I guess I'll speak to that.
>
> This is a very old program. I don't remember why I wrote it, but I'm
> sure I was doing some debugging on a program and was trying to
> fine-tune the performance, and needed a way to test how long it took
> to run after making improvements.
A naive way would be to use "PROMPT $t" and leave a TEST.BAT without
any "@echo off", and just calculate the difference shown in your head.
FreeCOM also (non-standard) supports "time /t" to print the current time.
> There are lots of programs out there
> to track the run-time of a program on DOS, and I probably gave a quick
> look around
I forget what 4DOS uses. Some programming languages (e.g. QBASIC and
REXX) have easy timing built-in. DJGPP always had "REDIR.EXE -t", and
DJGPP's port of BASH has the standard *nix shell built-in "time"
command. (DJGPP's libc also has uclock() which tries to use Pentium's
RDTSC or automatically falls back to something else via SIGILL if that
fails).
> I'm in favor to swap out the old Runtime with this Runtime. No issues here.
One minor enhancement would be to consider stderr sup
Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)
Hi, On Mon, Jun 17, 2024 at 6:41 PM Jim Hall via Freedos-devel wrote: > > You might be interested in this video I recorded yesterday about > running FreeDOS on the Pocket386: > https://www.youtube.com/watch?v=2h96UseZs6Q > > It shows several apps and games on the Pocket386, mostly running some > shareware games, plus Word for DOS, and As Easy As spreadsheet. Definitely cool. More videos of testing would be interesting. Try rebuilding the FreeDOS kernel with OpenWatcom on it, heh. Or install ZipSlack [Slackware 11, 2006??] Linux atop your FAT partition, I think it supports 8 MB of RAM. (Seriously, people always suggest an old Linux distro instead of DOS, but I think that's not realistic in most ways. Still, no worse than trying to run ancient Windows 3.1.) > If you're curious about its performance, here's a quick rundown of some > games and apps: [not all of these are shown in the video] > > Games: > > - Doom - runs fine at small size I did leave a comment suggesting Fastdoom from Github, which has been specifically optimized for 386s and 486s. * https://github.com/viti95/FastDoom > - Duke Nukum - runs fine, uses PC speaker 3D, right? Not the original 2D one? > - Rise of the Triad - runs fine at small sizes, uses AdLib for sound I forgot this was 386 DOS4GW. (It's based upon an improved Wolf 3D engine, which was 286 / VGA.) I assume Wolf 3D would run faster but maybe not. Hmmm, I vaguely recall some OpenWatcom 386 rebuilds of Wolf 3D. * https://github.com/TobiasKarnat/Wolf4GW > - Shadow Warrior - doesn't run (requires 9MB, this has 8MB) I have no idea. DOS4GW 1.97 is limited in total RAM available, but it does supposedly support VM swapping. But maybe they disabled that here (and/or it's too slow to be usable). You could also try "CWSTUB blah.exe" which supports swapping, but that may not work. > - Tomb Raider - crashes during setup (not a surprise, this is a 1996 > game and requires way more memory and CPU than this laptop has - the > game should have done a memory check) I don't think the Pentium (1993 debut) was really widespread even in 1996 (too expensive), but indeed it was much faster. But I also don't think a lot of things were optimized for legacy hardware (actual 386s) even back then. Quake (1996) has no chance on this machine, for instance. > - Wolfenstein 3D - runs great! Oh, okay, you did test this (it wasn't shown in the video). > - Biomenace - runs fine 286 / EGA, I love that game! > Apps: > > - Borland Turbo C++ compiler - editor runs fine, I've used the > compiler to write a few test programs, no issues there It seems quaint, but back in the day they told us the "optional" math coprocessor was an unnecessary expense and "wasn't needed" unless we were going to do a lot of scientific calculations. Normal home users didn't "need" it. (And of course every cpu since the Pentium has it included by default, go figure. Some software like GCC always assumed an FPU present.) Even ignoring that, the 386 itself was not pipelined like the 486, so the fastest instruction was like 2 clocks. So a comparably-clocked 486 (40 Mhz) would, in theory, run twice as fast. Also 486s often had (very small) on-chip caches which helped. But as far as cpu instructions, the 486 only offered very little advantage. Some expert (Michael Abrash??) once said that the 8086 and 386 preferred small code while the 486 was very sensitive to (code and data) alignment and preferred more RISC-y simpler unrolled code. I'm far from an expert, but docs always warned about AGI stalls and using suboptimal code sequences, even suggesting "blended" code (or separate code paths for distinct cpus). One thing that always bugged me was how much slower GCC (DJGPP) got in later versions after 2.7.2.1. That version ran okay on my 486, but later versions like 2.95.3 (even with -O0) ran much slower. In the race to constantly upgrade to newer hardware, a lot of software was just never optimized properly because nobody cared enough. In fact, I recall that GCC claimed that their 486 code was just the exact same 386 code only with extra alignment. Sad, really, that it never got the full support it deserved. (You can actually rebuild GCC 2.7.2.1 in DOS, I've done it. On my old Pentium it took about 10 minutes. I miss the days when things were simpler and faster!) I don't think GCC even got Pentium support until later (2.8.1). Pentium-scheduled code (U and weaker V pipes) was a big improvement on those machines (and no huge slowdown on older cpus). Not everything can be "fixed" or optimized to run at lightning speeds on such machines, but at least some noticeable improvements are definitely possible. Seriously, most code is just suboptimal, and without proper testing on old hardware you'll never be aware of it. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS on Pocket386 (follow-up)
Hi,
On Mon, Jun 17, 2024 at 6:42 PM Jim Hall via Freedos-devel
wrote:
>
> I wrote a "how-to" article about FreeDOS on the Pocket386 for
> Both.org, but I also copied/pasted this into a wiki article on the
> FreeDOS wiki:
>
> Now that I've reinstalled the Pocket386, my next step is to test every
> application and game from FreeDOS T2406. If you're curious how an app
> performs on FreeDOS on real hardware ('386-SX at 40 MHz, 8MB memory)
> I'll share notes in a follow-up thread.
Definitely interesting!
Since I don't have working legacy hardware anymore, I've done some
light, informal benchmarking of various tools under DOSBox-X (a "fast
486") in FreeDOS. It's definitely eye-opening (compared to my
semi-modern 2010 laptop). So things which seem instantaneous natively
run much slower when emulated. (This is actually good and lets me
optimize my code and compare compilers.)
> So far, I can report that FED is a bit slow to start up (just when I
> thought it had hung, it came up) but runs fine after that.
Is it UPX'd? LZMA compression is horribly slow on legacy cpus, that's
why it's disabled for 16-bit .EXEs by default. (Yes, I know this is a
32-bit DJGPP build.) If so, try unpacking and repacking with "--best"
instead.
A while back I tried running Linux under the web browser in a
Javascript-based emulator. It had GNU Emacs on there. Emacs took at
least a minute to boot up, but at least the syntax highlighting looked
pretty!
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Four in a Row (was: one more proposal for upload via fdnpkg)
Hi, On Thu, Jun 6, 2024 at 6:06 AM Jerome Shidel via Freedos-devel wrote: > > Looking around on the ibiblio and my server: > > There is a version that has a timestamp from 2019 in the ibiblio mirrored > files > > Then later, Jim found it as well in 2019 and mirrored it to ibiblio. Actually, there was a mailing list discussion (years ago) and I myself mirrored it to iBiblio for us. > I don’t see a reason that would require it to be excluded. > So, I recommend including it with the release starting with T2407. > > :-) Okay with me. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] prog lang. year for watcom compiler/programming book list?
Hi, On Fri, Jun 7, 2024 at 5:14 PM Richard Stoltenberg via Freedos-devel wrote: > > Just some notes; updates. People might want to stick to the pdfs if they need > bigger font. > LibreOffice may be able to save as html. Got the C Language book from Lulu > on Monday 3rd June. I forgot that even Richard Stallman wrote a C book that he gives away for free: _GNU C Language Intro and Reference Manual_ * https://lists.gnu.org/archive/html/info-gnu/2022-09/msg5.html * https://git.savannah.nongnu.org/cgit/c-intro-and-ref.git/tree/ > I read new standards for Ansi C were updating (2018). > https://www.iso.org/standard/74528.html maybe just bug fixes. > Thanks now can try to fix code. * https://en.wikipedia.org/wiki/C23_(C_standard_revision) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] problems with moving in a long history
Hi, On Sun, Jun 2, 2024 at 7:33 AM perditionc--- via Freedos-devel wrote: > > DJGPP is where the cmdline env and extended command line processing is from I > think, that or 4DOS. > it's been a while, but it was based on and made to function like existing > implementations. I think it was a Win95 feature originally. (But yes DJGPP supports it.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] prog lang. year for watcom compiler/programming book list?
Hi, On Thu, May 23, 2024 at 2:02 AM Bernd Böckmann via Freedos-devel wrote: > > C in general and Open Watcom in particular are good choices for DOS > programming. > > The other free options supporting more recent C versions are GCC as part of > DJGPP targeting 32-bit DPMI, and, > despite being somewhat experimental, IA16-GCC, a port of GCC for the DOS > 16-bit real mode target. Most DOS compilers never supported C99. Although I can appreciate parts of C99, you don't really "need" it for DOS. * https://en.wikipedia.org/wiki/C99 > Not exactly with examples, but for documentation specific to Open Watcom I > recommend their PDFs and / or > the printed manuals. At least the Open Watcom C Language Reference (it is > basically ANSI C with some but > not all features of C99 and implementation specific addons) and the > programmers guide would be a good idea > to have a look at after aquiring some knowledge of the C language. The DOS reader is "whelp cguide", IIRC. Not PDF but readable in plain DOS without third-party tools. _C in a Nutshell (2nd)_ is also a good book and even covers C11: * https://www.amazon.com/Nutshell-Definitive-Reference-Peter-Prinz-dp-1491904755/dp/1491904755/ref=dp_ob_title_bk ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] zoo
Hi, On Wed, May 22, 2024 at 11:17 AM tom ehlert via Freedos-devel wrote: > > am Mittwoch, 22. Mai 2024 um 13:14 schrieben Sie: > > it seems that no knowledgable person finds zoo interesting enough to fix it. > and those who care about zoo have no clue. > I regret that I have to say this. We had a discussion on BTTR a few months back with no obvious consensus: * https://www.bttr-software.de/forum/board_entry.php?id=21046 Do we want ZOO 2.10 (Cygwin sources) or 2.01 (public domain??) or Booz (unextract only, no subdirs) or Unzoo (new compression method only, subdir support)? If we need a Turbo C++ makefile, I can write one (since I did the same for NASM16 and NASMLITE back in 2019). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FETCH4FD
Hi, On Sat, Mar 23, 2024 at 2:14 PM Jim Hall via Freedos-devel wrote: > > And years ago, we used to include COMPINFO in a previous FreeDOS > distribution, but I don't remember why we stopped including it. If I had to > guess, probably it was the same question of "usefulness." I'd have to double check to be sure, but I believe it was old (limited) info and also had the TP7 Runtime 200 bug. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DX-FORTH?
Hi, On Wed, Mar 20, 2024 at 8:19 PM Bruce Axtens via Freedos-devel wrote: > > I stumbled over DX-FORTH this morning which purports to be "... a > Forth language compiler and development system for MS-DOS and CP/M-80 > operating systems. It is intended to be a complete, easy to use, > programming tool for the creation of turnkey applications." Is this a > language used at all in FreeDOS development? I have previously mirrored several versions of it to iBiblio for us. It's written in TASM and the bulk of it is public domain. However, I don't really grok Forth, so I've never used it much, but it looks fairly useful. * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/forth/dxforth/ Ed used to have a website, but I think he just dumps files to his Google Drive nowadays. I vaguely remember finding a newer version (two Januarys ago??). * https://groups.google.com/g/comp.lang.forth/c/Qx4GK4oJIpI/m/e4apQkQqAwAJ "ANN: DX-Forth 4.54" (Apr 29, 2023) * https://drive.google.com/drive/folders/1kh2WcPUc3hQpLcz7TQ-YQiowrozvxfGw Actually, that Drive link also shows DXDOS455.ZIP (Oct. 31) download: * https://drive.google.com/file/d/1CqIOOQ9uuenEIL-8BH3-kraxGP485GGN/view?usp=drive_link Enjoy. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] VME broken on Ryzen CPU, autodetection useful?
Hi, On Mon, Nov 13, 2023 at 9:19 PM Steve Nickolas via Freedos-devel wrote: > > I think there may be a point where if one's going to run DOS on > a modern machine, it'll have to be through some degree of emulation. > Whether that be a KVM/QEMU-on-metal approach, or a 64-bit "DOS" which can > emulate a Pentium MMX or so, VESA SVGA, SB16, etc. for legacy apps... > > (Actually, I'd be interested in something of this ilk if I knew more, > having run a stripped-down Apple //e emulator on bare-metal from UEFI and > then giving up because I couldn't read the damned Alt keys...) Just for comparison, for Raspberry Pi (ARM), *not* running atop Linux (or any other host OS): One guy emulates the old 8-bit CP/M OS (and Z80 cpu) via Ultibo (written in Free Pascal), thus allowing him to run Turbo Pascal 3 for CP/M : * http://www.projekte.daleske.de/prog/11_EMUZ80_RPI/prog_EMUZ80_RPI_en.htm Another guy tried porting Project Oberon (compiler and OS) to Ultibo : * https://github.com/MGreim/ultiboberon ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] VME broken on Ryzen CPU, autodetection useful?
Hi, On Mon, Nov 13, 2023 at 7:44 AM Eric Auer via Freedos-devel wrote: > > > Hi! I just got reminded that (2017 news) > > http://www.os2museum.com/wp/vme-broken-on-amd-ryzen/ > > VME is broken on AMD Ryzen of that time Ryzen (Zen 1) was brand new in 2017, redesigned from scratch. I doubt the current Zen 4 (2022) has that bug, but who knows. (Now that the BIOS and CSM are dead, they may not care to fix it. And the whole "x86-S" rumors imply legacy is going away.) > That sounds like > something which would be relevant for JEMM386, because it > could automatically activate NOVME mode for affected CPU. It's faster with VME (on Pentium and up), right? > Does anybody remember whether it does? * https://github.com/Baron-von-Riedesel/Jemm/releases v5.79 (Oct 31, 2020) "VME (virtual mode extensions) is now off by default; there exist CPUs that claim to support VME but actually don't." > And whether AMD has fixed the issue in later Ryzen or other CPU versions? Not sure. I'll search Google. * https://wiki.gentoo.org/wiki/Ryzen "Broken VME (Virtual-8086 Mode Enhancements) on 1st gen Ryzen 1st Ryzen processors generation had a broken VME implementation: 16-bits VM86 tasks within a 32-bits protected mode OS crash. This has been fixed by a later microcode revision" * http://www.os2museum.com/wp/vme-fixed-on-amd-ryzen/ Odd, the fix was mentioned on OS/2 Museum (in 2017, again). "The fix is shipped in the form of a microcode patch as part of AGESA 1.0.0.6, currently being rolled out by OEMs as part of a BIOS update. The patch level for the fixed microcode is 8001126 or higher. The older microcode revision 800111C (part of AGESA 1.0.0.4a) is known to have trouble with VME." But looking at this VOGONS thread, I'm unsure: * https://www.vogons.org/viewtopic.php?t=53952&start=20 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi, On Sun, Nov 12, 2023 at 5:46 AM Bernd Böckmann via Freedos-devel wrote: > > On 12.11.2023 02:44, Rugxulo via Freedos-devel wrote: > > But I still have not found an elegant solution yet to do a widening > conversion of an untyped pointer from near to far. > Should be rarely needed though. For a typed pointer FarAddr(thing^) does the > trick. You can get the current code segment or data segment with the CSeg and DSeg functions. * https://www.freepascal.org/docs-html/rtl/system/seg.html Also see the "absolute" keyword: * https://wiki.freepascal.org/Absolute ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi again, On Fri, Nov 10, 2023 at 7:56 AM Bernd Böckmann via Freedos-devel wrote: > > > > > I believe int64 was originally from Delphi. (Isn't there also "long > > long" support in OpenWatcom via "-za99“?) > > Yes, Watcom C supports 64-bit integer arithmetic, in contrast to Turbo C 3.1, > which to my knowledge does not, > but silently interprets „long long x“ as „long x“, yielding a 32-bit integer > type. Would something like this (assembly, 8086 and 386) help? "Fast 64-bit Signed Integer Arithmetic Routines (Roger Moser)" * http://cd.textfiles.com/ems/emspro1/ASMUTIL/QMATH0.ZIP Or how about this (32-bit assembly)? "Efficient [Unsigned] 64-Bit Integer Arithmetic in 32-Bit Mode (AMD)" * http://web.archive.org/web/2020110100*/https://sites.google.com/site/rugxulo/32math64.txt?attredirects=0 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi, On Thu, Nov 9, 2023 at 4:39 PM Bernd Böckmann via Freedos-devel wrote: > > > Could you please post the exact message you got from the compiler? > > For something like this "FarPointer(@Buffer)" I get the following error > message: > > "Error: Illegal type conversion: "Pointer" to "FarPointer"" > > My opinion is that this should be supported by the compiler, because it > is well defined for the small memory model I am working in. I had thought @ was just an alias for the built-in Addr() function. (In classic / ISO Pascal, you can't get the address of anything, and '@' is a character substitute for '^'.) A quick search shows this: * https://wiki.freepascal.org/FPC_New_Features_3.2.0 FarAddr internal function Overview: There's a new i8086-specific internal function, similar to Addr(), called FarAddr(), which always returns a far pointer to the address of its argument. Notes: The built-in Addr() function and the @ operator return a pointer type (near or far), that depends on the memory model. When interfacing with DOS, BIOS and other 16-bit APIs, it is sometimes useful to be able to obtain a far pointer to a pascal variable or procedure/function, regardless of the selected memory model. Previously, you would have to use ifdefs, or do something like Ptr(Seg(x), Ofs(x)). Now, this can be replaced with the much nicer FarAddr(x). svn: r37629 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Error compiling FreeDOS Kernel
Hi, On Wed, Nov 8, 2023 at 2:21 AM Walter Oesch via Freedos-devel wrote: > > I want to build the FreeDOS Kernel. Kernel 2043? Any particular reason to not use the stock build? Did you modify anything or add any patches? Just curiosity? > I use Dosbox in Ubuntu Linux and watcom comiler from FreeDOS, version 1.9. Which version of DOSBox? 0.74-3? Which Ubuntu? 20.04 LTS 64-bit? OpenWatcom can also run natively atop Linux. The old 1.9 installer had a bug where it needed "export TERMINFO=/lib/terminfo" first. You could also probably unzip it and manually install. (I assume it has a Linux makefile somewhere. It also had a MinGW makefile, IIRC.) You also need NASM and UPX. (You might need one older [or newer??] than 2.16.01.) > I changed config.b to use watcom and copied to config.bat, then start with > buildall.bat. > The compilation hangs in BOOT/boot.asm:437 Warning Must update constant > offset (17Bh)... > > What did i wrong? I don't know, but I'm not sure DOSBox is recommended (or even supported) for this kind of task. The only times I really rebuilt the kernel were atop FreeDOS itself (under QEMU or VirtualBox). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi, On Wed, Nov 8, 2023 at 2:21 PM Bernd Böckmann via Freedos-devel wrote: > > the tests I did showed that FreePascal is perfectly capable of producing > reasonably small binaries fitting the small memory model, if you do not > require the full language feature set (stay away from ObjFpc / Delphi > modes). SysUtils and exception handling pulls in a significant amount of > code, so you either stick with plain FPC or TP modes or have to live > with large memory model. FPC mode is the default and (I believe) allows function overloading and structured return values (with slightly different function pointer syntax). > I am not that interested in Turbo Pascal compatibility, so I can not say > anything about it. For me, FreePascal provides some benefits over Turbo > Pascal, taking my specific use case into account: e.g. 64-bit arithmetic > in 8086 real mode. I believe int64 was originally from Delphi. (Isn't there also "long long" support in OpenWatcom via "-za99"?) > To the specific problem: I have to provide a FAR pointer to the BIOS as > a member of an INT13 device access packet. That pointer shall point to a > 512 byte array, for which I get a near pointer via the @ address > operator. This near pointer has to be converted to a far pointer. > Because this operation is clearly defined for the small memory model, I > asked if someone knows that a built-in solution exists. But perhaps this > question is better addressed to the FreePascal community. In the > meantime, I will use the function from my last mail. Dunno, directly ask FPC guys MarcoV or NickySn. Sometimes they frequent the BTTR Forum too. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal near to far pointer conversion
Hi, On Wed, Nov 8, 2023 at 1:42 PM Bernd Böckmann via Freedos-devel wrote: > > has anyone recently played around with the FreePascal 8086 cross > compiler to generate DOS executables? I try to convert a near pointer to > a far pointer while working under the small memory model, but that is > not as trivial as it should be, because I have not found a language / > library feature for it. > > I came up with the following solution, but I am wondering if I have > overlooked something built-in? Try reading this: * https://wiki.freepascal.org/DOS#New_pointer_types Yes, I sometimes play around with FPC i8086-msdos, but I've never really messed with mixed memory model programming. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Phishing attack - warning!
Hi, Gmail caught one with its Spam filter. It doesn't show any prior emails from this person. author: th...@yamashita1921.com subject: Re: [Freedos-user] TASM under an emulator? link: urdirec.com On Thu, Nov 2, 2023 at 11:07 AM Mercury Thirteen via Freedos-devel wrote: > > ...as did I. Mine was as follows. > > From: webmas...@propstei-marien.de > Subject: Re: [Freedos-devel] Logger v0.3-BETA > Content: > Hi There, > Please look into the the document in the web-link down the page. > LINK BUTTON > Enjoy a good afternoon! > ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Interim Build T2310
Hi, On Mon, Oct 2, 2023 at 2:07 PM Jim Hall via Freedos-devel wrote: > > Jim wrote: > > I want to compile some things using IA-16 GCC in the new Interim Build > > T2310, but neither the LiveCD or BonusCD have the DJGPP Environment > > package on it. We had this on previous FreeDOS installs; to compile > > with IA-16 GCC, you need to set the DJGPP environment variable to a > > DJGPP.ENV file. > > > > Or is the DJGPP Environment package on one of the ISOs, and I've > > missed it somehow? > > > Jerome wrote: > > The DJGPP are massive. There is not enough room on the CDs for > > everything else when DJGPP is included. Off-hand I think those packages > > require something like 350Mb. > > > > Plus… there have been “complaints” that the DJGPP needed updating > > and some other tools/packages should also get included. > > > > I’m not a DJGPP user and don’t want to break those packages. So, > > I’m not updating them. > [..] > > Yes I saw the discussion about DJGPP being out of date and really big. > No problems there. I know the distro is getting really big (see also > below) and we should try to trim some things. I just wanted to compile > something with IA-16 GCC (not DJGPP) and found I couldn't because > something was missing in T2310 that IA-16 GCC needed. > > I wonder what the mininum extra stuff is needed from DJGPP to get > IA-16 GCC to work. I haven't tried, but I guess that's a project I'll > try to tackle soon. If it's a matter of crafting an ENV file, then > that's one thing. If IA-16 GCC really needs a bunch of stuff from > DJGPP, that may preclude IA-16 GCC if we don't have DJGPP. T.K. Chia's Gitlab site says this (untested by me): "Alternatively, if you do not wish to install DJGPP, just set a DJDIR environment variable thus: set DJDIR=c:\devel\djgpp" * https://gitlab.com/tkchia/build-ia16/-/releases Off the top of my head, I don't know of any hard requirements that I16GCC.EXE (etc.) needs from DJDEV205.ZIP. (The 386 COFF libraries are useless, for instance, presumably all of the headers too. The rest is mostly just misc. utils and info files.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Ré : Ré : T2308 invalid partition signature after format
Hi, On Sat, Sep 16, 2023 at 10:21 PM Paul Dufresne via Freedos-devel wrote: > > Sorry, the address was in octal, > > with -Ax to have the address in hexa it feels ok to me: Most people prefer "hexdump" these days: * https://man7.org/linux/man-pages/man1/hexdump.1.html * https://man.freebsd.org/cgi/man.cgi?query=hexdump&manpath=FreeBSD+13.2-RELEASE+and+Ports * https://man.openbsd.org/hexdump.1 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting FreeDOS kernel without a 386
Hi, On Fri, Aug 11, 2023 at 5:28 AM Paul Edwards via Freedos-devel wrote: > > Sorry for the delay. I've been sick recently (possibly Covid) > plus had other stuff to deal with. No fun, get well soon. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] CD-ROMs was ANSI for DOS
Hi, On Sun, Aug 6, 2023 at 9:05 PM Michael Brutman via Freedos-devel wrote: > > Just an opinion, but it's bad software design to assume that the presence or > a peripheral implies > a certain class of machine. The presence of a CD-ROM should not imply a 386 > or better machine; > it's orthogonal. Not sure this example helps your case, but Dragon's Lair (1983) was LaserDisc on a Z80! ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
Hi, On Tue, Aug 8, 2023 at 10:46 AM Kirn Gill via Freedos-devel wrote: > > On Mon, Aug 7, 2023 at 7:24 PM Rugxulo via Freedos-devel > wrote: >> >> Wikipedia says the 286 "was designed for multi-user systems with >> multitasking applications". OS/2 1.x targeted it. > > Multitasking requires no special hardware whatsoever. Cooperative > multitasking simply requires an API > designed to yield control to the next task upon a system call. Preemptive > multitasking only requires a timer > that generates a hardware interrupt with sufficient regularity. I have never used Desqview nor Desqview/X (DJGPP v1 SDK), so I don't know how those worked. But I have used DR-DOS 7.03's 386 multitasking. To me it was nice but limited use (to my usage scenario) because it was limited to 64 MB per task and required their DPMI (and their EMM386) to always be enabled. (DR-DOS also can run Windows 3.x but not quite run Win95 although allegedly comes close.) > ELKS - the Embeddable Linux Kernel Subset - performs preemptive multitasking > on an 8086. I never got around to trying ELKS. The lack of obvious releases (back in the day) confused me. I can't remember if they used a FreeDOS boot disk or not. They claimed networking and LFNs. It sounded interesting, but I was never sure what apps were precompiled for it (IIRC, using BCC/dev86). QEMU Advent Calendar had an image for it, but I don't think I ever got around to trying it. Comparatively, I've (rarely) run the 16-bit Minix 2.0.x a few times. They used segmentation to share static code between processes, I think (e.g. multiple instances of the same executable). Several caveats but still a cool OS. >> > > For >> > > instance, DR-DOS 7.03 supports "task swapping" on 286s but only >> > > "multitasks" on 386s. >> > >> > Yes, because it uses 386 hardware features to do multitasking. Its proprietary EMM386 doesn't need a separate HIMEM.SYS and has embedded VXDs (or something weird like that which I don't understand) and a built-in DPMI server. Although it reports "XMS 3.0", it really caps out at 64 MB. >> OS/2 was "a better DOS than DOS". Originally it was even codenamed >> "DOS 5", right? The so-called "European MS-DOS v4 that multitasks" >> used NE format in real mode. That's similar to OS/2 (which also used >> NE, as did Win 3.x). >> >> DOS was never their top priority, but it made them money. >> Compatibility was important (for a time). >> >> I doubt they originally intended to sell multiple OSes, but when you >> try to support 8086, 286, 386 ... what can you do? Ever-increasing >> memory amounts needed newer OSes and APIs. > > The original plan was to let Windows fade away after 2.x; there was an > engineer at Microsoft that mostly > improved Windows by himself enough to run all of the Microsoft Office > components at the same time > (a difficult, if not impossible feat under Windows 2.x of any flavor) and got > an executive's attention shortly > after the OS/2 launch with his experimental Windows build that it caused > Microsoft to repivot around DOS > and Windows again. Gordon Letwin had a long post explaining his view of the MS split from IBM: * https://groups.google.com/g/comp.os.ms-windows.misc/c/-iNeep60eVE/m/Xl5ddAtJENcJ?hl=en > My understanding is that OS/2 is a direct descendant of Multitasking MS-DOS > 4.10 (an even rarer update > to the already-rare multitasking 4.00) with a LOT of reengineering behind the > scenes. Limited analysis with > Ghidra, however, can neither confirm nor deny this hypothesis at this time. Most of the work on the 1.x (16-bit) versions of OS/2 was done by Microsoft. Supposedly their 32-bit "portable rewrite" is what became NT. (However, Win95 could still barely run atop a 386 with 4 MB of RAM, so it stuck around on the consumer side.) >> > > NT was not aimed at DOS software. It was incomplete in DOS support in >> > > many ways (and had a much higher footprint). >> >> Win95 had DOS features (FAT32, LFNs) that NT didn't get until Windows 2000. > > But back to DOS, NT's support for DOS is cruddy on purpose. It's meant as a > developer compatibility tool > to keep old compilers working, it wasn't really meant for consumer use. On > i386, it's uses the Virtual 8086 > Mode to implement a fresh DOS environment. Windows 3.0 and Windows NT 3.1 both had many DOS bugs that were only fixed later. Heck, Win95 had various bugs. Even XP (which "mostly" worked) had bugs. NT wouldn't run Quake because of its DJGPP's nearptr usage while Win95 could (with help from CWS of CWSDPMI). Some bugs in XP were w
Re: [Freedos-devel] dir issues
Hi, On Mon, Aug 7, 2023 at 7:45 AM Liam Proven via Freedos-devel wrote: > > On Sun, 30 Jul 2023 at 17:55, Rugxulo via Freedos-devel > wrote: > > > I believe "task swapping" was one of the main benefits of a 286. > > It's not a 286 hardware feature, no. > > It's a feature of DOS-compatible OSes of the 286 era. It's a software > feature not a hardware one. But it was enabled by XMS memory > management, something that a DOS could only do on a 286 or later. Wikipedia says the 286 "was designed for multi-user systems with multitasking applications". OS/2 1.x targeted it. > > For > > instance, DR-DOS 7.03 supports "task swapping" on 286s but only > > "multitasks" on 386s. > > Yes, because it uses 386 hardware features to do multitasking. > > > (This probably also goes back to IBM's own > > TopView, which predated DesqView.) > > I don't think TopView did much multitasking at > all, but the thing here is that the DesqView style of multitasking is > done in software and everything has to fit into conventional memory: > all apps share the base 640kB of RAM. Wikipedia says "TopView is the first object-oriented, multitasking, and windowing, personal computer operating environment for PC DOS developed by IBM". > The later 386 type of multitasking doesn't: it's using hardware to do > it it and the software is running in protect mode and has up to 4GB of > virtual address space to play with. > > It's a really big important difference. I'm sure you're more familiar with OS/2 1.x than I am. But clearly that multitasked apps on a 286 in protected mode. > > > Anyone who wasn't booting straight into Windows, and who still used > > > DOS apps, I configured the PC to boot straight into DOSShell instead. > > > I made menu entries for all their DOS apps, and one for Windows 3.x > > > too. > > > > Clearly OS/2 and/or Windows were considered the future. (Novell's > > attempt at improving DR-DOS failed against Win95.) > > Clearly according to whom? OS/2 was "a better DOS than DOS". Originally it was even codenamed "DOS 5", right? The so-called "European MS-DOS v4 that multitasks" used NE format in real mode. That's similar to OS/2 (which also used NE, as did Win 3.x). DOS was never their top priority, but it made them money. Compatibility was important (for a time). I doubt they originally intended to sell multiple OSes, but when you try to support 8086, 286, 386 ... what can you do? Ever-increasing memory amounts needed newer OSes and APIs. > > > [6] By 1993-1994 most PCs booted straight into Windows 3.1 but I made > > > launchers for their DOS apps in Program Manager, and in the > > > background, I hand-optimised their RAM with EMM386.EXE so there was > > > lots of free RAM for those big power-user DOS apps. > > > > Win95 was better. (I still have my overformatted "upgrade" Win95 floppies.) > > That seems a bit like saying that the wheel is better than fire. > > It's a different thing that happened at a later time. They are not comparable. As far as DOS compatibility goes, Windows 3.1 and 95 had a lot in common. > > NT was not aimed at DOS software. It was incomplete in DOS support in > > many ways (and had a much higher footprint). Win95 had DOS features (FAT32, LFNs) that NT didn't get until Windows 2000. > > > DOSShell was a great DOS app launcher and file manager, but didn't have > > > apps. > > > > Apparently "Visi On" in 1983 was the first (and yes, it did allow > > third-party apps in "restricted subset of C" for its VM.) > > I don't really see any connection here, TBH...? Wikipedia says "VisiCorp Visi On was a short-lived but influential graphical user interface-based operating environment program for IBM compatible personal computers running MS-DOS". ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
Hi, On Wed, Aug 2, 2023 at 2:29 AM Paul Edwards via Freedos-devel wrote: > > > FreeDOS should run on 8086, both kernel and shell. If it doesn't, > > that's a bug or omission. > > Are you sure? I thought I was told that the standard > distribution relied on an 80386. Jerome's work on the distribution overall (and a lot of software packages) requires 386. But the basics should still run on 8086. > > ke20xx_32.zip : binaries for 8086, FAT16, FAT32 > > I got this, and then renamed my kernel.sys to kernel.old, > > Regardless, I then burned the image onto the CF and > booted on the Book 8088 and I got the same problem. > "loading freedos" followed by incessant beeping. It's probably something else, but I don't know what. > > The very bare minimum (besides boot sector) is kernel and shell. What > > other pieces of DOS software did you need or want? > > Oh I see - thanks. I need fdisk and format and more > and doslfn and possibly xcopy, but it doesn't support > lfn, and zip and unzip. DOSLFN is 386. (You could maybe reassemble StarLFN for 8086 and use LONGNAME.DAT files to store the LFNs, but it'd be slow.) Zip and Unzip do have 16-bit versions, but I think FreeDOS normally ships the 32-bit versions. Check here for 16-bit versions (if needed): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/file/info-zip/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] ANSI for DOS
Hi, On Tue, Aug 1, 2023 at 3:24 AM Paul Edwards via Freedos-devel wrote: > > > However, most people don't care about standards, and even the ones who > > do don't really think anything "useful" can be written in them. Which > > is untrue and a shame. > > It is only recently - perhaps only a few hours ago - that I started > to have confidence that it was untrue. > > Ok, so an entire toolchain plus OS plus fullscreen editor can be > written - what definition of "useful" is being used? That's enough > to quite literally rebuild the world. I don't know, some people are never satisfied. I'm happy with Space Invaders or Tetris or Doom. Others prefer Minecraft or Fortnight or whatever modern Unreal or Unity game. I'm also happy with a simple 386 assembler, but others demand x64 with AVX-512, a full preprocessor, structs, unions, macros, HLL-compatible calling conventions, etc. My favorite utility is probably *nix Sed (which is related to Ed and Grep). So those are super useful to me. Others prefer a full HTML5 web browser with Javascript v5 (or whatever). I used to chide my brother with his quote "but it doesn't burn DVDs", so I think that's an unreasonable expectation for computers. But I'm not huge on multimedia (although I enjoy YouTube and Twitch). I like "simple" compilers. I like text editors. I like text manipulation tools. > > There are way too many competing languages, > > too. Something else is always "newer", shinier, more practical, more > > elegant, more popular, etc. > > Yeah, I'm not really trying to compete in that field either. You know what I mean. Pascal vs. Modula-2 vs. Oberon vs. Ada vs. Delphi C vs. C++ vs. ObjC vs. C# vs. D vs. Go AWK vs. Perl vs. Ruby vs. Python Or even C++11 vs. C++20 vs. whatever. It never ends. > Once I have the entire toolchain (just the C compiler is sort of missing - > SubC is only a subset of C90), then I am happy, in principle, to > start again from scratch in Pascal or Rust or whatever. But so > far I haven't even completed the "C venture" - even to the point > of answering the above question about migrating from one bitness > to another. C is a bit of a red herring. (Isn't everything?) ISO C alone isn't enough for POSIX 2008 (requires mmap). A lot of code depends on deleting open files (POSIX file system), for instance. And there's no (inherent) subdir support. I'm not complaining. Just saying, others' expectations and demands are much heavier than yours (and ours). > > It takes two to tango. Most people don't care about ultimate or > > theoretical portability. While I 100% agree with and sympathize with > > you, it's not interesting to them. > > Sure. I'm not really attempting to corner the mass market. Maybe > that will happen later, but it isn't priority at the moment. I'm more > interested in an 8080 (8-bit) OS, now that I have a NEC V20. Check out David Given's attempt at CPMish on Github: * https://github.com/davidgiven/cpmish > >> But I'm expecting to burn the latest UC8086 onto a CF > >> and boot it on my Book 8088 later today. > > It does work, but there was an anomaly. Clearing the > screen doesn't work. I took a look at how that is done, > and it is done by doing a scroll up. I suspect the bios > in the Book 8088 doesn't support that. I haven't yet > confirmed it. Isn't there an ANSI escape for that? Or does that not work either? "[2J" or something? (I think DR-DOS' shell did that for CLS.) > >> I don't think I can > >> even do that with the Freedos distribution I use as I think it > >> has a dependence on an 80386 processor. So for an > >> alternative to UC8086 I will be using MSDOS 6.22 and > >> ANSIPLUS. > > > The kernel should have an 8086-friendly build. The latest shell might > > be 8086-friendly too (although the old 2006 stable one was 186). > > I didn't really understand this comment, FreeDOS should run on 8086, both kernel and shell. If it doesn't, that's a bug or omission. I know I have some old floppy images that I ran under 8086tiny (and derivatives) and Joris' Retro. I never preferred a "386" kernel for FreeDOS because it was very minimal improvements and not worth it. We're talking a few minimal cycles shaved due to better instruction use (in real mode), that's all, no added features. Same with 186, usually not worth it. (Doesn't mean there isn't still room for improvement.) > so I simply burnt my > Freedos 1.3 onto a CF. It said "Loading FreeDOS" and then it > beeped continuously for 1-2 minutes, then it started making a > clicking noise, which I let run for 15 minutes or something > before switching off the computer. * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2043/ Contents of release zip files: ke20xx_16.zip : binaries for 8086, FAT16 ke20xx_32.zip : binaries for 8086, FAT16, FAT32 ke20xxsrc.zip : sources for the kernel * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/command/0.85a/ANNOUNCE (I assume these are the latest versions. Someone please correct me if not.)
Re: [Freedos-devel] ANSI for DOS
Hi, On Mon, Jul 31, 2023 at 8:38 PM Paul Edwards via Freedos-devel wrote: > > Yes, if you're prepared to add a curses layer, then you can > support both the standard, plus non-standard things like > a PC BIOS. But neither fullscreen application that I actually > used and care about (microemacs and msged) added that > layer (both added their own layer though). Yes, curses (lib) is what most *nix use. Wikipedia says originally the first curses library's code was borrowed from Bill Joy's vi (a famous full-screen editor, twice as popular as emacs). DOS also got ports of Stevie, XVI, Calvin, and VIM. There is still a DOS port of PDcurses, at least for DJGPP (386/DPMI). It was used in Hesseling's THE editor (among other things). Note that there were several so-called "microemacs" by different people, and different forks and versions. The VILE editor (vi clone) is based upon Daniel Lawrence's MicroEmacs, IIRC. (There is a DJGPP port.) I think there was some dispute over some of Conroy's code (later on). And OpenBSD used to bundle "mg2a" Emacs (no GNU regex by default). Minix 2 had Elle. DJGPP still has GNU Emacs (26.1 or such). Don't forget Freemacs (and FreeDOS). > > Shooting for platform independence is admirable. > > Sure. At some level I am trying to answer "what went wrong?". > And perhaps demonstrating what we could have had instead > if people had simply followed the standards. Although C90 > came a bit late for people to be in a position to follow. Scott Franco is a big fan of ISO 7185 "classic" Pascal. I built a version of (updated) P5 Pascal for FreeDOS back in 2013. That dialect predates both UCSD and Turbo Pascals. But he was hard set on only bootstrapping it with a similar "classic" Pascal compiler (e.g. GNU Pascal / GPC), which is rare. However, with Scott's work, I was able to salvage P4 (circa 1976), reuse p2c, and get that to build with either OpenWatcom or GCC. P4 isn't nearly the full standard nor nearly as efficient as P5, but it's better than nothing (IMHO). Both of those are "public domain". However, most people don't care about standards, and even the ones who do don't really think anything "useful" can be written in them. Which is untrue and a shame. There are way too many competing languages, too. Something else is always "newer", shinier, more practical, more elegant, more popular, etc. I know I've mentioned some of this before. Just wanted to give you some idea. > If you do setvbuf NBF to switch off buffering of stdin, it is assumed > that by default that the C library will switch into raw mode and > switch off line buffering, so that all the platform-specific code > that would otherwise need to be done to achieve that (all the > tset stuff on Unix e.g.) is hidden away in the C library. Libraries like curses just hide (or build atop of) termcap and/or terminfo on *nix. It's a big mess. Even the OpenWatcom installer on Linux relies on terminfo, IIRC. > But in reality there is no requirement for the C library to actually > do that that I am aware of, and I'm not aware of anything other > than PDPCLIB that does that. So if using an arbitrary C library > your application would be forced to add platform-specific code > after all. It takes two to tango. Most people don't care about ultimate or theoretical portability. While I 100% agree with and sympathize with you, it's not interesting to them. They only care about "modern" systems (which still ship commercially and are fully supported). Most sympathy with DOS went away after WinXP (unsupported in 2014) or Win9x (unsupported in 2006). AMD64 didn't help. Even VT-X took forever and only helped emulators. I think a lot of people underestimated how hard it would be to fully emulate (properly) in software. > I'm not stating that Microsoft is embracing the exact same > concept that I am (not saying they're not either), but I don't > think it is so black and white that the microemacs that I just > released as source and DOS binary is inherently useless. Windows 11 is 64-bit only and doesn't have NTVDM anymore. > Of course you can say that UC8086 itself is inherently useless > too. Definitely not. But I haven't tried it yet. "A poor carpenter blames his tools." Most people lack imagination (or hope). > But I'm expecting to burn the latest UC8086 onto a CF > and boot it on my Book 8088 later today. I don't think I can > even do that with the Freedos distribution I use as I think it > has a dependence on an 80386 processor. So for an > alternative to UC8086 I will be using MSDOS 6.22 and > ANSIPLUS. The kernel should have an 8086-friendly build. The latest shell might be 8086-friendly too (although the old 2006 stable one was 186). What else did you rely upon? I would definitely not bother with old MS-DOS. > Linus said that his Unix would never be as sophisticated as > what was it? SCO? I've forgotten. Almost no-one else has even > heard of it to even forget. Linus has said that if FreeBSD's 386 kernel was already available, he p
Re: [Freedos-devel] dosshell and task swapping, was: dir issues
Hi, On Sun, Jul 30, 2023 at 12:19 PM Eric Auer via Freedos-devel wrote: > > VCPI was a small interface added to things like EMM386 which gave other > apps access to things they would normally no longer reach after DOS gets > locked up in a VM86 task by EMM386. While it is nice that it is small, > it is not so nice that it basically lets you kick out other protected > mode things to use them yourself. DPMI is significantly larger, but it > lets you use protected mode in s far more cooperative way. Which is why > protected mode hosts like DOSEMU and Windows would typically only offer > DPMI, not VCPI, because VCPI is too raw metal, too little cooperative. DPMI could run in ring 3 and also optionally supported 286s (as well as 386s) while VCPI was ring 0 and 386 only. > itself, so your app only has to deal with ONE interface: DPMI :-) When the host OS' DPMI (e.g. Windows Vista) is buggy, there is no escape. > > In fact, quite a few > > apps and games were "EMS only", even 386+ programs. (It was only DJGPP > > v2 in 1996 where they went "DPMI only".) > > Are you sure you mean apps? Maybe specific DOS extenders? Which? Scream Tracker 3 (for sound samples) and Blackthorne (game) come to mind. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
Hi, On Fri, Jul 28, 2023 at 11:51 AM Liam Proven via Freedos-devel wrote: > > For me, when I worked with, supplied and supported DOS in the late > 1980s and early 1990s, the chronology went like this: > > [2] DOS 4 came along. It was a memory hog, but it had big-disk support > (over 32MB) and DOSShell, so it caught on. DOSShell was *much* better > than batch files, and quicker and easier too. It also obviated the > need for things like Xtree for file management. DOSShell, like most > other DOS menu apps, could swap itself out of memory so it only took a > tiny bit of space, like a single-digit number of kB. Nobody minded > that. I never used DOSShell much. I always used other file managers (in limited ways because it hides the cmdline, which is much easier to use for utilities and programming), e.g. Tutordo, Dos Controller, Necromancer's DOS Navigator, Doszip. Some people frown upon the "hard to use" cmdline, but it's scriptable and you can automate so much. The "interface" can be arcane, but I don't see the speed advantage to "add graphical widgets and mouse support". I find the mouse "mostly" redundant for most tasks. I personally find GUI overrated, TUI underrated, and cmdline (usually) easy enough to use. > [3] Windows 3.0 started to catch on. That meant HIMEM.SYS and XMS as > standard; LIM-spec EMS started to fade. Apps like 1-2-3 r3 used DOS > extenders routinely. Memory management really got important but > everyone was buying 386SXs so you could sell them QEMM even if they > didn't want Windows. VCPI was a superset of EMS, right? That was co-designed by QuarterDeck (DesqView company), right? It was meant to make multitasking more stable, but DPMI (later invented for Windows 3.0 but also implemented elsewhere) was much better designed and more popular. Before Win95, all you had was 32-bit DOS extenders. By the time Vista (and its DPMI "limit") came out, nobody cared anymore. The other complication was the different versions (e.g. XMSv2 versus the bigger 386 variant v3) and whether your EMM386 could share XMS and EMS at the same time. There were various complications there. Since the XMS standard and support was so "late", several compilers (e.g. Turbo C) only enabled "use EMS" by default. In fact, quite a few apps and games were "EMS only", even 386+ programs. (It was only DJGPP v2 in 1996 where they went "DPMI only".) > [4] DR-DOS 5 bundled the memory management of QEMM and for a while it > sold really well, even for people who did want Windows. DR-DOS 5 was their equivalent to MS-DOS 3.3. (Version numbers were a marketing ploy.) > [5] MS-DOS 5 copied all the good bits from DR-DOS 5, and DOSShell got > even better. Now it did task swapping: you couldn't multitask, but you > could pause any standard DOS app, switch back to DOSShell, *and launch > a new app*. I believe "task swapping" was one of the main benefits of a 286. For instance, DR-DOS 7.03 supports "task swapping" on 286s but only "multitasks" on 386s. (This probably also goes back to IBM's own TopView, which predated DesqView.) The DesqView/X SDK used DJGPP v1, but I don't know much about that (or DesqView in general). > Anyone who wasn't booting straight into Windows, and who still used > DOS apps, I configured the PC to boot straight into DOSShell instead. > I made menu entries for all their DOS apps, and one for Windows 3.x > too. Clearly OS/2 and/or Windows were considered the future. (Novell's attempt at improving DR-DOS failed against Win95.) > [6] By 1993-1994 most PCs booted straight into Windows 3.1 but I made > launchers for their DOS apps in Program Manager, and in the > background, I hand-optimised their RAM with EMM386.EXE so there was > lots of free RAM for those big power-user DOS apps. Win95 was better. (I still have my overformatted "upgrade" Win95 floppies.) > Then Win95 came along and it all went away. :-) I didn't care because > I'd switched to NT 3 at work and OS/2 2 at home. NT was not aimed at DOS software. It was incomplete in DOS support in many ways (and had a much higher footprint). NT also wasn't (at that time) intended for gaming. OS/2 2.x (and up) was the 32-bit OS after IBM and MS parted ways. So IBM was handling it all themselves. > > Years ago, I thought DOS GUIs were interesting. I liked that folks > > were writing GUIs like SEAL and oZone, and continuing to work on > > OpenGEM. But of those, only OpenGEM really has much application > > support. Even so, there aren't many GEM apps to run in it. But there > > are a ton of regular DOS apps. > > The thing is this, IMHO. > > There are 2 conflicting goals here: > > [a] a GUI that has its own GUI apps > [b] a good app launcher and file manager that doesn't try to be a GUI > > GEM is a good low-end GUI and it has apps. It's not a great DOS app launcher. > > DOSShell was a great DOS app launcher and file manager, but didn't have apps. Apparently "Visi On" in 1983 was the first (and yes, it did allow third-party apps in "restricted subset of C"
Re: [Freedos-devel] Virtual get-together?
Hi, On Sun, Jul 30, 2023 at 11:03 AM Gregory Pietsch via Freedos-devel wrote: > > Wasn't a virtual get-together supposed to happen about now? -- Gregory Maybe Jim is still under the weather? ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] dir issues
Hi, On Sun, Jul 23, 2023 at 7:08 AM perditionc--- via Freedos-devel wrote: > > On Sun, Jul 23, 2023, 7:54 AM Liam Proven via Freedos-devel > wrote: >> >> AFAICS you never explain. What is "HX"? > > https://www.japheth.de/HX.html > > HX DOS-Extender is a free DOS extender with built-in Win32 PE file format > support Note that HX 2.16 is a much-older version, and Japheth no longer updates the website. Newer releases (e.g. 2.20) are all on Github: * https://github.com/Baron-von-Riedesel/HX/releases ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Happy 29th anniversary to FreeDOS!
Hi, On Thu, Jun 29, 2023 at 12:46 PM Jim Hall via Freedos-devel wrote: > > In 1994, several of us got together around a pretty neat idea. > > We liked DOS, but Microsoft was clearly moving completely to Windows. "The > next version of Windows," they said, "would do away with DOS." > > We wanted to keep DOS around, so we decided to write our own. That project, > announced 29 years ago TODAY on June 29 1994, was the FreeDOS Project. > > Thanks to EVERYONE who is (or has been) part of FreeDOS! 29 years is a long > time for any open source project, and I'm looking forward to more years to > come. Congrats to my favorite operating system. (In fairness, there are other great OSes too, not just the obvious ones.) My own birthday was yesterday, and 1994 was when I got my first IBM PC (with MS-DOS 6.00 and Windows 3.1). You've done great work, keeping the legacy alive. There was so much cool stuff for DOS over the years (not just games). I'm particularly fond of compilers and utilities myself. I will forever think that some people are geniuses for their work on FreeDOS like Eric Auer. It's just amazing what some people accomplished. I was only able to contribute very small stuff, but hopefully it helped anyways. The spotlight may have faded for DOS over the years, but that doesn't diminish their hard work. Dedicated fans like us will never forget all the cool stuff that was accomplished with it. May it live forever in emulation. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FDISK 1.3.7 and HTMLHELP 5.3.6
Hi, On Mon, Jun 26, 2023 at 5:56 AM Bernd Böckmann via Freedos-devel wrote: > > I released FDISK 1.3.7. > > I also pushed HTMLHELP 5.3.6 to the unstable branch at gitlab. > > It everything goes well both should be included in the next interim build. Thank you for your work on these. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
Hi, On Mon, May 22, 2023 at 11:04 AM wrote: > > On May 22, 2023, at 7:03 AM, Rugxulo wrote: > > On Mon, May 15, 2023 at 6:48 PM wrote: > >> > >> Let me show you a MEM print out from my Pentium Pro: > >> > >> NANSI3,536(3K) 0(0K) 3,536(3K) > >> SHSURDRV 400(0K) 0(0K)400(0K) > >> LBACACHE10,576 (10K) 0(0K) 10,576 (10K) > >> CTMOUSE 3,104(3K) 0(0K) 3,104(3K) > > > > NNANSI [sic] can unload, so if you switch to that, all of these can > > optionally be unloaded (if you put them last) to free up memory. Of > > course, SHSURDRV will also unload your whole XMS RAM disk, too. > > Sure. But... > > Even with loading and keeping all that stuff, the system still has 94K free > upper memory and 84K of that is consecutive. > > Unloading those drivers would not free up the 11K of Low memory used by the > Kernel. > It would just free upper memory of which there is plenty. My bad, I didn't notice and assumed it was all in conventional. > The largest executable size is 628K. > Nothing should every require over 600K of low memory to load. I agree that 600 kb is too much for any reasonable app, but it does sometimes happen (esp. games). I think I saw a demoscene app once that also required that much. Very wasteful. (But even DOS compilers aren't that lean and mean. Smartlinking and overlays are a lost art.) > Actually, that MEM print out is outdated for that machine. Just to use up > some more upper memory, > it now loads CWSDMPI at boot. That brings free upper memory down to about > 45K. But if upper memory > gets too low or their are compatibility issues, I’ll stop loading it at boot. It's 32-bit "DPMI only", no "extensions". So OpenWatcom 32-bit or old Borland 16-bit DPMI stuff might complain. You might also want to disable swapping via CWSPARAM for your old hard drive since it tries to create a CWSDPMI.SWP file by default on C:\ drive. > Side Note: At boot, the system transfers the main OS files over to RAM disk, > reconfigures the environment > accordingly and primarily runs from RAM. Much better performance. A lot less > wear and tear on 25+ > year old drives. Besides, it has got to do something with all that RAM under > DOS. Oh, absolutely, it's way faster in RAM, even compared to USB jump drives. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I want my 10K
Hi, On Mon, May 15, 2023 at 6:48 PM wrote: > > Let me show you a MEM print out from my Pentium Pro: > > NANSI3,536(3K) 0(0K) 3,536(3K) > SHSURDRV 400(0K) 0(0K)400(0K) > LBACACHE10,576 (10K) 0(0K) 10,576 (10K) > CTMOUSE 3,104(3K) 0(0K) 3,104(3K) NNANSI [sic] can unload, so if you switch to that, all of these can optionally be unloaded (if you put them last) to free up memory. Of course, SHSURDRV will also unload your whole XMS RAM disk, too. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] CPU flags register not updating on interrupt calls
Hi, On Sun, Apr 30, 2023 at 4:54 PM wrote: > > In, kernel/pcb.h, I see some notes about “offsets must match the assembly > process” > and a couple of different layouts for the offsets. Could this be related to > the issue I am having? > I am using NASM 2.16.01 and Watcom 1.9. Someone reported that there was a regression in OMF/OBJ for NASM 2.16.01 regarding 16-bit segments. Try reverting to NASM 2.15.05 instead: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/2.15.05/ Or, for really having fun, try the ancient 0.98.39 16-bit version: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreePascal bug [off-list]
Hi,
On Wed, Apr 12, 2023 at 7:10 PM Jim Hall wrote:
>
> > I believe this is a Free Pascal issue because the short
> > hello world test works, but if you decide to use any
> > objects, the Video unit is completely missing.
I don't do a lot of graphical programming, so I'm unfamiliar with the
"Video" unit.
"9 Units that come with Free Pascal"
"9.1 Standard units"
* https://www.freepascal.org/docs-html/user/userse47.html#x157-1640009.1
It lists several, including "video":
"
video
Provides basic screen handling in a platform independent way, and
supports writing custom drivers.
"
I don't think this is meant to be "{$mode tp}" [turbo] compatible
(which only had "graph" and text mode "crt").
What are they trying to do, SVGA? VESA? Maybe something like Allegro
(lib) could help.
> > There is
> > reference to consolidation of the video functions but no
> > references to where the the functions in that unit went.
It's probably only used internally by some FPC utils, if even that
much. Maybe it has no maintainer or bitrotted, I don't know. But I've
never seen it used.
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bug 0x5801/41
Hi, On Fri, Apr 7, 2023 at 11:46 AM tom ehlert wrote: > > and - well I understand that kernel version control is a complete > mess - but Kernel 0.85a seems a bit unlikely given that > https://github.com/FDOS/kernel/blob/master/docs/history.txt refers to > 0.42. * https://github.com/FDOS/kernel ... says this: "FreeDOS kernel - current 0xFD version is 2.43 (2043)" Try "ver /r" if in doubt. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, On Mon, Mar 20, 2023 at 5:20 PM Rugxulo wrote: > > On Mon, Mar 20, 2023 at 5:06 PM Bret Johnson wrote: > > > > This is something much more serious than a "tradeoff" or a > > "regression". My new i5 CPU appears to be spending _at least_ 99% > > of its resources NOT processing OpCodes and NOT accessing the > > cache (because there isn't one). And the problem is blamed on > > "sub-optimal code". I don't know what the CPU is doing with all > > those resources it has, but I do know what it's NOT doing. I do know > > that what's going on inside a CPU is very complicated. Call me naive, > > but I always thought the primary purpose of a CPU was to process > > OpCodes. Silly me. > > > > >> I think it probably > > >> would be -- I certainly think it would be WAY faster than my 3.3 GHz > > >> i5. > > > > > nope. > > > > Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5? > > And again, I know it doesn't make any sense, but it's still true. > > Self-modifying code?? Seriously, older machines were faster with self-modifying code, but newer ones are much more sensitive and slower. Anything within a (roughly) 4 kb radius gets slowed down dramatically. I noticed this, years ago, on my old AMD TK53x2 laptop. * https://en.wikipedia.org/wiki/Self-modifying_code#Interaction_of_cache_and_self-modifying_code "In some cases short sections of self-modifying code execute more slowly on modern processors. This is because a modern processor will usually try to keep blocks of code in its cache memory. Each time the program rewrites a part of itself, the rewritten part must be loaded into the cache again, which results in a slight delay, if the modified codelet shares the same cache line with the modifying code, as is the case when the modified memory address is located within a few bytes to the one of the modifying code." "PC processors must handle self-modifying code correctly for backwards compatibility reasons but they are far from efficient at doing so." Maybe speculative execution is affected by this, too? * https://en.wikipedia.org/wiki/Speculative_execution ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi again, On Mon, Mar 20, 2023 at 5:06 PM Bret Johnson wrote: > > This is something much more serious than a "tradeoff" or a > "regression". My new i5 CPU appears to be spending _at least_ 99% > of its resources NOT processing OpCodes and NOT accessing the > cache (because there isn't one). And the problem is blamed on > "sub-optimal code". I don't know what the CPU is doing with all > those resources it has, but I do know what it's NOT doing. I do know > that what's going on inside a CPU is very complicated. Call me naive, > but I always thought the primary purpose of a CPU was to process > OpCodes. Silly me. > > >> I think it probably > >> would be -- I certainly think it would be WAY faster than my 3.3 GHz > >> i5. > > > nope. > > Even though a 350 MHz K6-2 is WAY faster than my 3.3 GHz i5? > And again, I know it doesn't make any sense, but it's still true. Self-modifying code?? (joking) Or maybe you have FDAPM loaded? ;-) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] How to setup a compiler for FreePascal on Fedora Linux to FreeDOS 16 bit
Hi, On Sun, Mar 19, 2023 at 11:16 PM Paul Dufresne via Freedos-devel wrote: > > I am thinking about using FreePascal to write programs for DOS. > > Writing an "hello world" program in FreePascal for 32 bit DOS (Go32) is easy, > because the fpc package can be installed > with fdimples from the Live installer. > > But there is no 16 bit FreePascal directly for DOS. > So one have to used some other OS like Windows or Linux, and use a FreePascal > cross-compiler to 80186 16 bit DOS. If you unpack / install the Windows version (ppcross8086), you can then use it with HX DOS extender (so both DOS host and target): * https://github.com/Baron-von-Riedesel/HX/releases > I say 80186, because this is the precompiled version, you would have to > compile your own cross-compiler for like 386 16 bit DOS. > And now I am realizing that 80186 is kind of too advanced for FreeDos that > prefer 8086... but I think the older > FreePascal can do is 80186. Like you later mentioned, it does also support 8086 (and 286, 386 ... not sure how "improved" those are, though). > Rather than using fpc to compile a .pas file, you use: ppcross8086 > as describe in: > https://wiki.freepascal.org/DOS > which is not too clear, that's why I am writing this. The Wiki is a bit outdated (esp. now that it's not only a snapshot but an official release). But generally you use a (separate) cross compiler for anything other than 386 (i.e. ppc386). Even the 64-bit compiler (ppcx64) is a cross compiler, IIRC. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] I wish I had a boot.log file
So you want a TEE utility? Or just to single step through it all (F8)? Try pressing the Pause key. (Yes, I know that's timing sensitive, sorry.) On Sun, Mar 19, 2023 at 10:30 AM Paul Dufresne via Freedos-devel wrote: > > So many messages on boot I cannot scroll back. > If only the boot process would also copy everything in a boot.log file! ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Booting and FDAPM
Hi, On Fri, Mar 17, 2023 at 5:32 AM wrote: > > At present, the FreeDOS installed system and installer boot media load FDAPM > on many hardware configurations and virtual machines. > > As most are aware, there has recently discussed issue that the watcom > installer was taking an excessively long time to install. The problem only > occurred when FDAPM was loaded. This was regardless of which power saving > options were used. Should we cut back on when it is loaded? I almost forgot that the Borland IDE tools were also slowed down when FDAPM was loaded. That is a known issue. > What I’m thinking is we more or less keep things as they are. But, add an > exception to the various AUTOEXEC files that skips loading it as a driver > when the OS is running under a known VM like VirtualBox, VMware, etc. > > Any thoughts? Yeah, just turn it off if under a VM (and document why with a REM comment). Oh, and turn on IDLEHALT like Tom suggests. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
Hi, Just for completeness On Thu, Mar 9, 2023 at 4:22 PM Eric Auer wrote: > > This is a self-extracting ZIP file. You can try using our > build of infozip UNZIP to extract it. Maybe the downloaded > exe uses build settings which are not fast for DOS or which > expect more than 32 MB RAM. Maybe it even uses a swapfile? It does use the Causeway extender, which indeed can swap. Unless they changed something, the old behavior was to swap the ENTIRE amount of used memory to disk (if needed), not just the extra part needed (a la CWSDPMI). So 37 MB RAM usage (e.g. paq8o8z) on a 32 MB physical RAM computer (my old Pentium) would swap all 37 MB (while CWSDPMI would only swap 5 MB). > I also expect that extracting 4000 files in DOS, some of > the directories containing 100s of files (samples/clibexam, > h/nt, binw, binnt, ...) to be slow without a decent cache > and generally slow because our caches do not write-combine. > > If you had 500 MB RAM, you could extract to a RAMDISK ;-) I always favored large RAM disks for MetaDOS. Heck, I also do that for my bootable USB drive for increased speed (since flash is roughly 2x slower to read and 5x slower to write). It's faster to do compilations that way. > You could test how long it takes to extract the files > in Windows and then boot FreeDOS and use either COPY or > XCOPY, with or without a cache, to copy it. I remember > a thread where I suggested an XCOPY patch to pre-allocate > all clusters before incrementally copying file contents, > in order to avoid frequent incremental FAT updates, but > I do not remember whether pre-compiled XCOPY binaries > with this patch are available. It may improve speed :-) IIRC, Doszip (Hjort) used your tip for faster copies: * http://www.bttr-software.de/forum/board_entry.php?id=8862#p8879 BTW, I've never seen any huge slowdowns in FreeDOS. This report was a bit scary to me! But luckily it was (AFAIK) a false alarm. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
Hi, On Mon, Mar 13, 2023 at 4:26 AM Wilhelm Spiegl wrote: > > after several tests I found the reason for this strange behaviour. > It disappeared when I booted from a virtual diskette without fdconfig / > fdauto.bat and executed watcom.exe. Same from HD. > Then I added fdconfig again - it was still fast. > Finally I found out that line (in about 62) caused be brake. > "lh fdapm apmdos" > This command appears three times in the autoexec.bat (lines 40, 62, 76, maybe > it varies a little) and is used there depending on the machine types. > Putting the command "lh fdapm apmdos" to "rem" made the watcom.exe > installation file work as it should. > > I asked Eric Auer, he recommended tests without "lh" - or replacing apmdos > by the softer "fdapm ADV:REG" but this gave the same slow > speed I had before. > > So I wonder if it is really necessary to install energy saving in FreeDOS > live CD, or, at least to check where > the machine runs (bare metal or vm which needs more engergy at all). IIRC, there's also a FDCONFIG setting of IDLEHALT which can already help somewhat. Outside of applications which constantly poll, it should reduce (virtual) cpu usage to less than maximum. Anyways, I just now booted up old QEMU 6.1.0 (64-bit) atop dead Win7 and used MetaDOS 0.7 (kernel 2041, 128 MB RAM, half of that is RAM drive) with old curl 7.64.1 to grab the relevant OW 2.0-c installer .EXE (which uses Causeway). Grabbing 140 MB with Curl took me five minutes. Installing a not-quite-full DOS toolset (roughly 33 MB) took two minutes. This was atop a virtual hard disk (FAT16) of 510 MB, no VT-X needed! NASM 0.98.39 (16-bit) built and worked okay, so did MiniSed, so did p2c. What didn't work was compiling TinyAsm (for some unknown reason, probably a bug). So I guess this issue can be closed. (Further testing results are still welcome.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, On Thu, Mar 9, 2023 at 4:29 PM Bret Johnson wrote: > > The computer I'm currently using is a few years old, old enough that I can > boot DOS on the actual hardware. > The CPU is an Intel i5-4590 running at 3.30 GHz. * https://www.intel.com/content/www/us/en/products/sku/80815/intel-core-i54590-processor-6m-cache-up-to-3-70-ghz/specifications.html So four cores? But only one core is running under DOS (albeit at max clock speed). But even "Turbo Boost" depends on your motherboard and BIOS enabling it for you. It doesn't go into detail about cache beyond saying "6 MB smart cache". I assume most of that is L3, then some L2, with a very small L1 (usually like 64 kb split between instructions and data ... not sure about writeback). Hey, I'm a noob, but some things are faster than others. The Pentium (586) had 8 kb cache, right? And the 486 was much more sensitive to code alignment. But the Pentium had U and (weaker) V pipes while the 486 was only pipelined. I think the Pentium 2 (686) was when they started adding "out of order" instruction rescheduling. Things like ALU or barrel shifter or register renaming or branch prediction also matter. > I have a DOS program I wrote a long time ago, called SLOWDOWN (and hope to > find time to "update" it in the future). The purpose of SLOWDOWN is to slow > the computer down so that DOS applications don't "blow up" because the > computer is too fast. It's not a perfect solution, but is useful in certain > situations. > > One of the things SLOWDOWN needs to do is figure out how fast the computer is > running so that it can slow it down the correct amount when you want to do > that. So, SLOWDOWN can sort of be used as a "benchmark" to see how fast your > computer actually is. > > For my test, I compared how fast my current computer runs (with a 3.30 GHz > clock speed) against a 33 MHz 386 CPU (which I measured way back when -- I > don't have access to that computer any more). At least in theory, because my > current clock speed is 100 times as fast as the 386, my current computer > should run _at least_ 100 times as fast as the 386 did. Also, at least in > theory, it should be even faster than that since the new computer has a cache > and the 386 didn't, modern CPU's take fewer clock cycles per CPU instruction, > etc. So what instructions are you testing? The original Pentium (586 circa 1993) had a pipelined FPU that Quake utilized in their hand-optimized code. Also, all Pentiums below 120 Mhz had the FDIV bug. Surely some of the slowest instructions are DIV / IDIV. > In fact, the new 3.3 GHz i5 CPU runs about 10 times faster than the 33 MHz > 386 did, not more than 100 times like you would expect. Floppy is always slow, optical drives are slow, virtual memory is slow, etc. Even networking can be slow. USB flash drives tend to be twice as slow to read and five times as slow to write. So a software cache and a RAM disk can help a lot. > I then ran a second test where I disabled the cache on the CPU (you can do > this with my CPUCACHE program which is included with SLOWDOWN). This is a > more "apples-to-apples" comparison of the _actual_ CPU speed than the > original test with the cache enabled. When I did this test, the computer ran > almost exactly the same speed as the 33 MHz 386 (it was about 3% faster, not > 10,000% faster as "logic" would dictate). There is something VERY wrong > going on here. I suspect you may not believe my results, but they are > nonetheless real. Sometimes regressions happen. It's a tradeoff. The Pentium 4 was worse at "inc eax" than "add eax,1". It also didn't have a barrel shifter, so shifts like "shl eax,1" were slower than "add eax,eax". That cpu was deeply pipelined, meant to scale up in raw clock speed (not to mention new SSE2 instructions). Like I said, early P4s were slower than high-end P3s. Newer cpus do usually need a recompile to be maximally efficient (for various obscure reasons). Here I'm also thinking of weird things like (SSE3) FISTTP and (FPU) FNSAVE / FXSAVE, not to mention weird optimizations like "REP RET" or "RET 0". (They also used to say "don't use LOOP, it's slow", but AMD sped it up again.) I've also noticed that some of my (semi-modern) cpus run (186) ENTER much much slower than its 8086 instruction equivalents. Not sure why, maybe they didn't think anyone would use it (most don't anymore, but some old compilers do). > So, given this real-life data, how exactly is what I said untrue, > oversimplified, inaccurate, unrepresentative, or any other similar adjective > you would choose to use? According to the theory, what I said can't be true, > and yet it is. I'm sure somebody will claim something like, "modern CPU's > are optimized for modern applications so you can't expect them to run old > stuff, like DOS, very well." Well, I think it's pretty unreasonable to > expect a modern 3.3 GHz i5 CPU to run at almost the exact same speed as a 33 > MHz 386 and with a straig
Re: [Freedos-devel] Open Watcom v2 DOS installer is abysmally slow in FreeDOS
Hi,
On Wed, Mar 8, 2023 at 3:12 PM Volkert via Freedos-devel
wrote:
>
> On Wed, Mar 8, 2023 at 11:35 AM tom ehlert wrote:
>>
>> > Over a month ago, I opened an issue on the FreeDOS project on
>> > GitLab about the Open Watcom v2 installer being extremely slow in
>> > FreeDOS. It takes an hour or more on FreeDOS, while the same
>> > installation completes on MS-DOS 7.1 within just a few minutes.
>>
>> either you report your config.sys and autoexec.bat for both tests
>> or your report is basically useless.
>>
>> write caching smartdrv (which freedos is known not to have) makes a
>> HUGE difference for installers, so you are comparing apples to oranges.
>>
>> of course running both without autoexec/config.sys would place them on
>> an equal playing field.
>
>
> OK, that's a fair point. When I have time again, I'll try to do more of an
> apples-and-apples comparison
> between the two, and then I'll share my findings here.
>
> An installation time of an hour still seems excessively slow though, even
> when no disk cache is loaded.
What does BUFFERS (config.sys) say?
What kernel version (ver /r)? Try again with an older (e.g. 2041) kernel.
Is this atop FAT16 or FAT32?
What host and guest cpus are you using?
How much RAM is available? (Use more than 64 MB.)
Does anyone know what extender (e.g. Causeway) the installer is using?
What VirtualBox version? Is VT-X enabled? (Recent versions only run on
64-bit hosts with VT-X enabled.)
And yes, disable DOSLFN ("doslfn d") first, if it's loaded.
(Sorry, I haven't tried it myself.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, On Wed, Mar 8, 2023 at 8:57 AM Liam Proven wrote: > > On Tue, 7 Mar 2023 at 14:50, Bret Johnson wrote: > > > The problem is, the CPU's _themselves_ really haven't gotten a whole lot > > faster than they were in the 386 days. > > Drastic oversimplification to the point of not being true, accurate or > representative. I'm not sure what he meant there (N.B. not a big deal) nor whether he meant a literal 386. Because the 486 was twice as fast as the 386 at the same clock speed. (The fastest 386 instruction was 2 cycles.) Was he comparing it to RISC design? The Pentium Pro was atrocious at 16-bit code, focusing on 32-bit. And early Pentium 4 models were slower than fast Pentium 3s! In particular, the Pentium 4 was redesigned to be able to scale up to 10 Ghz, but my the time the Pentium-D (3-ish Ghz) came out, it used too much power, so they scrapped it and went back to the Pentium-M (IIRC, the mobile Pentium 3 with SSE2) for the future Core 2 cpus (2006). Even compared to 2004, a lot has improved in cpus, so yes they are overall much faster. * https://www.phoronix.com/news/2004-CPU-3990X-Plus-FX-9590 > I'd say Koomey's Law replaced Moore's Law circa 2007-2008, when the > x86 industry went through the multicore transition. From ~1975 to > ~2005: CPU bandwidth approximately doubled every ~1½ years. Since > ~2005: bandwidth increases ~10% every 1½ years. Wikipedia says "Moore's law is the observation that the number of transistors in a dense integrated circuit (IC) doubles about every two years." This does not strictly mean performance improvements, but most people interpret it thus anyways. Either way, I've enjoyed FreeDOS (in one form or another) on whatever machine I could find. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi again, On Tue, Mar 7, 2023 at 12:41 PM Rugxulo wrote: > > On Tue, Mar 7, 2023 at 8:50 AM Bret Johnson wrote: > > > > That model sort of illustrates the concept, though. Both Windows and Linux > > want to manage the _entire_ machine's > > resources while they are running and one OS must give give up that control > > to let the other OS take over. > > I'm proposing that the control be outside either OS -- in a sense, give it > > back to the "BIOS". The "BIOS" in this case > > can be considered a common Hardware Abstraction Layer (HAL) that all OS's > > can share, but it could be "subdivided" > > (e.g., a "memory BIOS" and an I/O BIOS" and ...). Some might consider that > > a step backwards, but I'm not so sure. > > The direction we've been heading may actually be backwards, or at least a > > dead-end. > > Maybe you mean something like this? > > "Apple’s MS-DOS Compatible 486 Macintosh from 1995!" -- LGR Or maybe something like this? * https://en.wikipedia.org/wiki/Genode ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS Interim Build T2303
Hi, On Tue, Mar 7, 2023 at 5:59 AM wrote: > > > On Mar 6, 2023, at 10:19 AM, Bernd Boeckmann via Freedos-devel > > wrote: > > > > I noticed edlin32 2.21 is not working because of missing dos4gw.exe, but > > perhaps that is already obsoleted by the 2.22 release? A quick fix is copying CWSTUB.EXE (Causeway) to DOS4GW.EXE. Then it should work. Or run WDOSX's STUBIT on it. > Gregory has only been releasing edlin updates in source form. That requires > me to compile them. > For most projects, if a precompiled binary is not provided, I won’t compile > them. It get’s to be a very > time consuming process putting all the dependencies together and a successful > compile. At least > for edlin, that is not the case and it is not difficult to compile. But that > is all I do, I don’t go through > the process of attaching a stub to the 32-bit version. So, it still requires > the external dos4gw. > Which as you noted is not normally present. Use the "-l=causeway" flag with WCL386 to attach it when compiling and linking. > Maybe, I should just not bother compiling the 32-bit version for DOS. I think normally 16-bit Edlin is compiled with the Compact model, right? It doesn't mean someone somewhere wouldn't also need a 32-bit pmode version, but I think a 16-bit Compact build is good enough for our needs. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, On Tue, Mar 7, 2023 at 8:50 AM Bret Johnson wrote: > > That model sort of illustrates the concept, though. Both Windows and Linux > want to manage the _entire_ machine's > resources while they are running and one OS must give give up that control to > let the other OS take over. > I'm proposing that the control be outside either OS -- in a sense, give it > back to the "BIOS". The "BIOS" in this case > can be considered a common Hardware Abstraction Layer (HAL) that all OS's can > share, but it could be "subdivided" > (e.g., a "memory BIOS" and an I/O BIOS" and ...). Some might consider that a > step backwards, but I'm not so sure. > The direction we've been heading may actually be backwards, or at least a > dead-end. Maybe you mean something like this? "Apple’s MS-DOS Compatible 486 Macintosh from 1995!" -- LGR "The Power Macintosh 6100/66 DOS Compatible is a fascinating machine. For $2,199 in 1995 you got MS-DOS and Mac OS in one computer, thanks to an Intel 486 and a PowerPC 601 inside! Yeah, mid-90s Apple was rather amusing." * https://youtu.be/9UclHrIIaYA ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DOS Swappable Data (SDA) Area
Hi, Apologies if this is *slightly* off-topic. On Fri, Mar 3, 2023 at 7:01 PM Bret Johnson wrote: > > Let me just say that the computing world would be a VERY different place than > it is now if Operating Systems > (and maybe even BIOS's) were re-entrant. For one thing, MS probably never > would have became the monolith it did. > I'm not necessarily saying I think it would have been a GOOD idea, but just > that things would be different. The BIOS idea (separate, in ROM) was invented by Gary Kildall, right? Apparently CP/M-86 had a billion derivatives including (according to Wikipedia) Concurrent CP/M-86 3.1 with optional PC-MODE, aka "Concurrent DOS", which eventually evolved into DR-DOS. * https://en.wikipedia.org/wiki/Multiuser_DOS#PCMODE There was also (DR) Novell DOS 7, which supported 286 task swapping and 386 multitasking. And many other (unreleased) projects like "Star Trek": running Mac OS 7 atop Novell DOS on x86. * https://en.wikipedia.org/wiki/Star_Trek_project But Caldera focused on Linux, so even when they won their lawsuit against MS, they didn't really develop DR-DOS past 7.03 in 1999. (Tiny point releases were made to OEMs or other vendors.) I don't really understand it. It's hard to blame MS for everything. DR clearly had a lot of good releases, but many of them never caught on. I guess when you already have OS/2 and Windows and DOS (and Linux and ...), you don't need ten bazillion more. (I used to fervently read OSNews and try things in VMs or burn CDs to boot. Certainly there are dozens of worthy OSes.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] MS-DOG (was Re: [Freedos-user] FSF)
Hi again, I was thinking about this old email and thought I should clarify (in a technical sense). (comments below) On Wed, Mar 31, 2021 at 6:56 PM Jim Hall wrote: > > Here's the thing: I've had years of direct experience with Stallman. > > He calls DOS a "DOG operating system." The FSF and GNU websites > actually referred to MS-DOS as "the M$-DOG operating system" for > years. When I talked to Stallman about it, he doubled down on that > statement and said I was a "DOG man" because I worked on FreeDOS. And > he said anyone who uses FreeDOS is a "DOG user." Maybe Stallman > thought that was funny. FreeDOS is my favorite operating system. I've spent thousands of hours playing with it. I also like dogs, so never would I be offended by being called a "dog man". It's entirely possible that Richard dislikes DOS that much. It's also possible that he was just being funny. Either explanation is irrelevant because our enjoyment and use of FreeDOS does not rely on his preferences. "A poor carpenter blames his tools." But FSF used to sell CD-ROMs with DJGPP binaries. "Current" DJGPP 2.05 has Emacs 28.2 and GCC 12.2. So how bad can DOS be? I actually am pretty sure that "MSDOG" is an old article by Morten Welinder (a big contributor to DJGPP and Emacs back in the day). * http://www.delorie.com/djgpp/doc/msdog.html * https://www.gnu.org/software/emacs/manual/html_node/emacs/Acknowledgments.html The article by Morten is mostly technical in complaints but also obsolete (written in 1995). It covers "file system", "kernel", "shell" (the main culprit, by far), and "utilities". (Don't like FreeDOS? Fix it! "Patches welcome.") A lot of it doesn't apply universally to all DOSes anymore. It mostly targets MS-DOS 6.22. So specific bugs don't exist with other vendors, and all known improvements and workarounds are not mentioned (solving at least 80% of the problems). In particular, like I said, Morten contributed to DJGPP, which was always a *huge* boon to developers with many excellent tools that (also) avoided or fixed most of these problems. If the default DOS shell is despised as too weak or buggy (e.g. GNU Make wisely avoids it, if possible), there are plenty of other scripting tools available. In summary, out of 38 complaints: improved: 1, 3, 7, 8 workaround: 9, 15, 16, 17, 23, 25, 27, 30 vendor-specific: 2, 4, 5, 6, 10, 14, 18, 21, 22, 26, 28, 29, 33, 34, 35, 37, 38 irrelevant: 11, 12, 13, 19, 20, 24, 31, 32, 36 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Mon, Feb 27, 2023 at 5:59 PM Aitor Santamaría wrote: > > As a matter of curiosity, given that we were unable to find a precise answer > to why Microsoft dropped IFS after MS-DOS 5.0 (although we had speculations), > I thought, why not ask ChatGPT (Bing) about that? > > I had hoped that there was some page that we weren't unable to find. Or even > it could have been better if ChatGPT had any access to information from > Microsoft that was not easily publicly accessible. > Neither seems to be true. Search engines are notoriously bad for anything niche. Heck, even popular stuff gives lots of wrong answers. There's still info out there, but you have to ask the right person. Most stuff is tucked away in storage or hidden in some retired guru's brain. The tech world overall is sadly not very interested in archaeology, neither preserving nor emulating nor documenting "obsolete" stuff. "Today and tomorrow" are all they care about. Everything else isn't important to them (mostly). > As a lover of computing archaeology, I fear that when Mr. Gates passes away, > we will have to do with ChatGPT's answer. Oh well. I'm not understanding exactly what you want to know. (But someone like Michal Necasek of OS/2 Museum probably could answer.) PC-DOS was the version for IBM hardware, and MS-DOS was licensed to others. While Microsoft was mostly responsible for DOS (and OS/2), IBM still played a heavy role. At least Wikipedia says "MS-DOS 4" was mostly IBM's work. When IBM "fired" MS, (AFAIK) IBM still had access to sources for Windows 3.0 and MS-DOS 5.0. So they kept updating PC-DOS until, what, 2003? MS-DOS 5 came out in 1991, right? And OS/2 1.0 came out in 1987. OS/2 was supposed to be "the future", and MS was primarily responsible for OS/2 1.x (the 16-bit version). 32-bit OS/2 didn't come until 1992, and 32-bit Windows NT (aka "MS's portable OS/2 rewrite") was 1993. NT did support HPFS, for example, for a few years. So why did the "buggy" DOS 4's IFS interface not survive? They were focused on other OSes. Wikipedia says that OS/2 later got drivers for UDF and JFS. Obviously NT preferred NTFS (journaled, unlike HPFS, with larger max file size) and eventually dropped booting atop FAT (e.g. Vista) for security and performance reasons. It could also just be a RAM issue. IIRC, the standard answer why Windows tools won't create FAT more than 32 GB is because it's too slow (esp. for a real-mode driver). Maybe they never could happily get a working HPFS driver for DOS. (The 16-bit HPFS driver for OS/2 allegedly only supports a 2 MB cache maximum.) So if nobody uses it or it's too buggy or it only helps a competitor OS, then why bother? (Sigh.) For example, a few years ago Linux removed the ext3 [sic] driver because they only needed ext2 and ext4 (backwards compatible). The main reason for keeping ext2 as a separate driver was because it was much cleaner and simpler code. (Besides, I guess some storage media won't require journaling.) Sorry if I am confused, I'm just trying to understand it myself. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Free FDISK interim builds
Hi, On Sun, Feb 26, 2023 at 1:07 PM Bernd Boeckmann via Freedos-devel wrote: > > in the last two weeks I ported Free FDISK to Watcom C and started fixing the > bugs people mentioned > at the bttr forum and in the issue trackers. Great news! Thanks a ton for your work on this. BTW, it seems you still use NASM (instead of WASM). Seems redundant (no offense). > For people wanting to track the progress, I am doing the development at the > following repository: > https://github.com/boeckmann/fdisk. > > I will make merge requests to upstream https://github.com/fdos/fdisk in > regular intervals > > If you want something to be changed please send me an e-mail. I will try to > implement it if time permits it. Is makefile.bor still maintained? Do you still (also) support building it with that toolset (presumably freeware-ish TC++ 1.01 would work)? * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.BOR 1. Invoking TLINK with a toolset path is unnecessary. You can use "tcc" (or bcc) to link as well. 2. You also don't need to manually create temporary linker response files. (I forget exactly, but it's something like @&&^ ... ^ to do it automatically.) See here for an example: * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/n16tcmak.zip Regarding OpenWatcom: * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.WAT 1. Again, you don't need to manually create a temporary linker response file. Try using "LD = *wlink" instead, it will automatically handle long command lines. 2. "if exist *.OBJ @rm *.OBJ" is unnecessary, and you should be able to delete multiple files with Wmake's built-in "rm", e.g. "rm -f *.obj *.err *.lnk" with no error messages if not found. 3. Oh! And %UPX% is possibly a bad variable name since I think that's what the environment variable is also named, so that will override any internal makefile variable by default (if the user has set it). I recommend "PACKER" and "PACKERFLAGS", but this is not majorly important. Again, here's an example "makefile.wcd" of mine (but ignore the older Borland makefile in there): * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/asm/nasm/0.98.39/8086host/nasm16.zip ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Wed, Feb 22, 2023 at 5:19 PM Bret Johnson wrote: > > As an aside, I'm wondering if anybody has a "fool-proof" test for FAT32 > capability in the kernel. In USBDRIVE > what I currently do is go through all the drive letters and see if any of > them responds correctly to INT 21.7302h > (Get Extended BPB). This test works if there is at least one existing FAT32 > drive letter, but will fail if there are > no actual FAT32 partitions even if the kernel supports FAT32. I don't know > of a direct or fool-proof way to detect > FAT32 support, but maybe somebody else has come up with something. I believe DJGPP utils (2.04 beta or newer, e.g. 2.05 current) use the naive method of "only assume FAT32 if DOS version is 7". (By this I mean "du.exe","df.exe" etc. will then use INT 21h, 7303h.) "INT 21 - Windows95 - FAT32 - GET EXTENDED FREE SPACE ON DRIVE" * http://www.delorie.com/djgpp/doc/rbinter/id/40/32.html What about INT 21h, 71A0h? (Admittedly, it may assume the Win95 LFN API is available.) "INT 21 - Windows95 - LONG FILENAME - GET VOLUME INFORMATION" * http://www.delorie.com/djgpp/doc/rbinter/id/23/32.html Returns: ES:DI buffer filled (ASCIZ, e.g. "FAT","NTFS","CDFS") ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, I got bored (despite already knowing about this history), so I started watching Nostalgia Nerd's video on "AARD" (re: Win 3.1 beta atop DR-DOS) on YouTube. "Windows’ Hidden Self Destruct Code | Nostalgia Nerd" * https://youtu.be/TIfNIWn2Ad4?t=753 (comments further below) On Wed, Feb 22, 2023 at 3:20 PM Aitor Santamaría wrote: > > Well, thanks to all that contributed to this interesting topic (there are > quite a few interesting mails in the thread). > > I could find very little extra information, like this: > > https://www.os2museum.com/wp/dos/dos-4-0/ > > Also I found references on IFSFUNC: in 2Fh (AH=11h), IFSFUNC functions seem > to be entangled with the network redirector functions: > > http://www.ctyme.com/intr/int-2f.htm > > Apparently, these functions would be made available by IFSFUNC.EXE (curiously > not provided by kernel itself). > So I suppose the current only way to know more would be to acquire a MS-DOS > (or IBM-DOS) 4.0, disassemble this file. > > My conclusion would be that it looks like an alternative functionality update > to the network redirector itself (and not something entirely unrelated), that > tried to solve some of the previous problems and/or tried to be more abstract > and less tied to internal DOS structures, that was implemented only in DOS > 4.0, probably to try and make HPFS available for DOS, but that was later > abandoned (due probably to high memory requirements) in favour of maintaining > the old redirector). I'm not sure where this pseudo-code came from (Geoff Chappell?). But this is what the above video mentions (12:33 in): IF redirector running (INT 2Fh AX=1100h) AND IF default upper-case map (INT 21h AX=38h) in DOS data segment (INT 2Fh AX=1203h) OR IF no redirector AND IF FCB-SFT header at paragraph-boundary (offset == 0) THEN DOS is considered okay Just wanted you to know. (Yes, it's mostly irrelevant.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] More on Packages
Hi, On Wed, Feb 22, 2023 at 7:53 AM wrote: > > So…. > > There is only an old version with sources. Or, a newer version without > sources. We only have 1.1 of P5 mirrored (so far). I've built 1.4 (pcom.exe, pint.exe) locally but haven't run the test suite yet. (He changed it so my old GNUmakefile isn't good enough anymore.) Mostly it's just extra error checking, no added features. (In particular, he didn't want to extend P5 beyond ISO 7185 level 0.) > What about the zips on ibiblio from 2020 for r67 and r76? No binaries? That's p5c (ISO 7185 level 1), based upon p5, but it's written in C and targets (modern GNU/Clang) C, e.g. GCC 12.2 (DJGPP). r67 is an older version and should be moved to "old/". The latest seems to still be r76. * https://sourceforge.net/projects/pascal-p5c/ > Maybe I can coax you into creating a fresh build. ;-) > > Then hopefully, the community could agree to include it on the BonusCD. > > :-) I do also have p5c.exe locally (built with DJGPP), but it's not hard to build (his readme tells how). Most of the rest of the .ZIP is documentation or extensive examples and tests. I don't demand a package for any of this. Just saying that I found it interesting to fiddle with over the years. (But as Ralf said, some people dislike classic Pascal. So it may not be a popular opinion.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] More on Packages
Hi, On Tue, Feb 21, 2023 at 10:22 AM wrote: > > On Feb 21, 2023, at 3:19 AM, jer...@shidel.net wrote: > [..] > I’ve not looked into P5 Pascal. It would be nice to have a alternative to FPC > for DOS. > > > I just took a quick look at P5 at https://sourceforge.net/projects/pascalp5/ > > I did not see any binaries for DOS. Can it target DOS? Since it is able to > compile itself, it might be capable of creating those binaries. > > Or, maybe they can be convinced to make next version P6 available to DOS. P5 is a full "ISO 7185" (classic Pascal, Wirth's original) version of the P4 "public domain" bytecode compiler (and interpreter) subset from ETH Zurich. The binaries (pcom.exe, pint.exe) were only compiled and tested (by me) with GNU Pascal (e.g. GPC / DJGPP). * http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/pascal/p5/ Specifically, Scott (on SourceForge) only targeted Windows and Linux with separate .sh and (DOS-unfriendly) .BATs. So I wrote a GNUmakefile and built and tested 1.1 for DOS, Linux, and Windows. (Latest is 1.4, but I still haven't fully bothered yet. It's minor changes.) He kinda just does his own thing, so he never mirrored any of those builds. So I mirrored the DOS build for us. p5pas11.zip == (full sources and docs and tests, built with DJGPP 2.03p2 in 2013) p5-dj205.7z == (binaries only, built with DJGPP 2.05 in 2017) P6 will be 64-bit only because Scott doesn't seem interested in supporting 32-bit, sadly. So DJGPP it out. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Sun, Feb 19, 2023 at 7:39 PM Aitor Santamaría wrote: > > Does anyone know if the IFS (Installable File System) API is documented > anywhere? I have no idea if this link will help you, but I'm mentioning it "just in case" (because it sounds useful and impressive). * https://ecsoft2.org/ihpfs Basically, it's a read-only HPFS driver for DOS (last updated by Veit Kannegieser). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] More on Packages
Hi, On Mon, Feb 20, 2023 at 1:37 PM wrote: > > Other possible new packages to consider for inclusion (or at least watch): > > 386SWAT - GPLv3, Debugger (may require someone to compile) > https://github.com/sudleyplace/386SWAT You mean the old compile isn't sufficient? (IIRC, it was on his website.) > GW-BASIC - MIT License, Microsoft’s original 1983 version > https://github.com/microsoft/GW-BASIC Personally, I would rather have a package for P5 Pascal. (Although both is fine, too.) (But my .ZIP was old 1.1, and I never got around to testing or building 1.4 for us. No huge differences, just better error-checking, supposedly.) > DIFPAT, GPLv2, DIFF and PATCH Utilities > https://github.com/deverac/difpat Haven't tried these. Usually I just use the 32-bit DJGPP builds of the GNU ones. If these are really 16-bit, that'd be cool. (There are other tools in the wild, too, especially for non-text binaries.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Needs testing: SJGPlay
Hi again, On Mon, Feb 20, 2023 at 7:31 PM Rugxulo wrote: > > On Sun, Feb 19, 2023 at 3:58 PM Jim Hall wrote: > > I haven't checked the new sources (IIRC, it was said to be BASIC ... > PowerBASIC??). Does it also include ACD kit (or whatever third-party > lib)? This release does not include the sources to "ACDkit", only binary files (libs, etc). Can this be fixed? Who wrote ACDkit? Where is it currently found? What is the license? (Do we need a replacement? It can't be THAT hard!) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] IFS API
Hi, On Mon, Feb 20, 2023 at 6:41 PM Ralf Quint wrote: > > (just for example, DOS maintains > only one single date for a file, "Time modified", while on NTFS and > OS/2, you have additionally, "Time created", "Time access" as well. Some OSes do update "time created" for FAT. (There was a patch for the FreeDOS kernel in recent years, but I can't remember if it was ever officially included.) IIRC, "ctime" wasn't normally available to DOS itself unless DOSLFN (or similar) was loaded. I think (once loaded) DJGPP utils would then read it correctly. I did vaguely find that useful sometimes. But "access time" is often shunned as wearing out the drive for little reason, so (naively) I thought most Linux distros mounted as "noatime". ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Needs testing: SJGPlay
Hi again, On Mon, Feb 20, 2023 at 7:31 PM Rugxulo wrote: > > On Sun, Feb 19, 2023 at 3:58 PM Jim Hall wrote: > > > I used to use SJGPlay a lot (back in the day). I loved it. But I > haven't tried again in many years. > > > Could anyone with a CD player and a sound card on their computer > > please test SJGPlay with actual music CDs I found some old 2007 emails I sent him: >>> I can't get SJGPlay for DOS to work under XP. Windows 95/95 no problem. Ah, >>> the price of progress. >>> Freebasic looks interesting. I should try compiling SJGPlay with it someday. The old .EXE worked fine (years ago), so unless something changed (i.e. recompiled with different tools), then it shouldn't be a problem. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Needs testing: SJGPlay
Hi, On Sun, Feb 19, 2023 at 3:58 PM Jim Hall wrote: > > I wanted to start a new thread for this request. Based on the > discussion from the "FreeDOS package issues" thread, Jerome identified > that the CDP package didn't include source code. Robert suggested > SJGPlay as a replacement. I used to use SJGPlay a lot (back in the day). I loved it. But I haven't tried again in many years. (I liked the karaoke aspect even if I don't sing.) It was very well made. > Could anyone with a CD player and a sound card on their computer > please test SJGPlay with actual music CDs and comment here if SJGPlay > works well. (I don't have a CD drive on any of my computers, so I > can't test this myself.) I haven't checked the new sources (IIRC, it was said to be BASIC ... PowerBASIC??). Does it also include ACD kit (or whatever third-party lib)? (Eric's CDROM2 is maybe too minimal, but I still found it cool.) ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Proposal: remove Graphical Desktops from next FreeDOS
Hi, On Wed, Feb 15, 2023 at 5:28 PM Danilo Pecher wrote: > > Quite frankly, I would throw them all on the scrap heap. I wouldn't quite "throw them away", but for simplicity we really don't have to include them. I don't use any GUI in DOS (by default). > As Jim said, none of them has any number of apps worth noting I thought GEM included an art program and a word processor?? > and there is a reason why no GUI other than Windows 3.11 ever took off under > Dos. Desqview/X? (The devkit for that is still on DJGPP mirrors under "v1" whatever.) Calmira?? > I know that from painful experience of wasting two years on an attempt to > create one in the early 90s. It's just not what Dos is about, I think. DOSSHELL was quite nice (although I rarely used it). Same with Desktop2. However, for mixing tools and writing scripts and testing things, a UI is usually more of a hindrance than anything. (DOS Navigator was also very nice. In some ways I prefer TUI without mouse.) There were a *lot* of cool DOS programs and toolkits. For DJGPP alone, there was mGUI, JPTUI, Allegro, and others. It's sad how much got deprecated or ignored for DJGPP. It really is a swell suite of tools. > Unless someone puts together a serious attempt (perhaps PCGeOS > qualifies) I wouldn't include any GUI. Frankly, if you are after a > freeware GUI OS, Linux or ReactOS are better options. I wouldn't include any with FreeDOS "by default" either. I disagree about Linux as a suitable GUI for the same family of machines. There are not a lot of good distributions for old machines anymore. Something like ZipSlack (Slackware 11.0) is nice but from 2006. Well, I guess that's no worse than what we have, but it's unsupported and few would use or recommend it. Last I checked, the oldest supported Linux kernel upstream was from 2016. People are already giving up on IA-32 and even trying to split up x64 into separate groups (e.g. AVX2 or AVX-512, ugh). Chromebooks are quickly obsoleted too (which the FSF calls "planned obsolescence"). I'm not blaming anyone for not wasting time or money, but if something is shunned *and* unsupported, it makes little sense to say "just use Linux" when it either literally won't work (anymore) or nobody will develop with it or for it. Or did you mean TinyCore or some variant of Puppy? * https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Email Oblivion
Hi, On Wed, Jan 4, 2023 at 4:11 PM wrote: > > Due to some changes at the current registrar I use for my SHIDEL.NET domain, > my email was broken for the last week or so. > > If any of you attempted to contact me or if I missed something that required > my attention, I would not have received any messages. So if there is anything > you need to point out to me, you will need to resend it. Glad you're doing okay. Yeah, I sent one trivial email (that bounced), but since you're busy I don't think it's super important to resend. Thanks again for your work on FreeDOS, and don't stress too much in the New Year. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] FreeDOS floppy edition boot disk lacks an editor?
Hi, On Mon, Dec 5, 2022 at 8:58 AM Bret Johnson wrote: > > FWIW, the one I use is also called TED and is an old utility from PC > Magazine. The executable is only about 3 kB > (way smaller than the EDLIN that comes with MS-DOS) and is a VERY basic text > editor with a TUI > (it's not a line-oriented interface like EDLIN so is more intuitive to use). > It gets the job done efficiently for things like > editing CONFIG.SYS & AUTOEXEC.BAT. I used e3-16 (Wordstar keys) since it was super tiny (roughly 3 kb), but it was limited to CR+LF files and max 32 kb, which is imperfect. But for boot disks it was great in a pinch. Besides executable size (and license, ugh), you also have to worry about key bindings. I also like SteVIe (a vi clone), which is quite good in various ways. My normal favorite TDE also has a real-mode version, but I probably wouldn't prefer that (nor even an older version) for floppies. You really don't want a 160 kb editor on a floppy (unless you copy it to a RAM disk). ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Problem with procedural types in 16-bit DOS FreePascal
Hi,
On Sun, Nov 6, 2022 at 9:08 PM Jerome Shidel wrote:
>
> Make sure your compiling to the correct memory model. (I think huge, but
> you’ll need to double check that)
Default is Small, e.g. "-WmSmall". I assume "-WmCompact" would work
better for you?
> You may need to ensure the actual procedure is declared with far.
>
> Procedure Test; far;
> Begin
> End;
In old freeware TP 5.5, that would be {$F+} at the top and {$F-} at
the bottom of the procedure. (I believe all procedures within the same
unit / file are near while external procedures are far by default.)
> Also, you may need assign the address to a plain pointer and typecast the
> call.
Is that needed??
> Also, there are also compiler directives for FPC regarding compatibility.
Default dialect is "fpc", which is less strict than {$mode tp}, e.g.
it does change function pointer syntax a bit, but it also gives you
structured return types and function overloading.
{$asmmode intel} is only default for {$mode tp} as well (but you can
manually enable it, too).
Don't forget you can also declare inline functions! (Like real
inlining, not just inline machine code.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Hi, On Tue, Nov 1, 2022 at 3:40 AM Liam Proven wrote: > > On Fri, 28 Oct 2022 at 19:29, Robert Riebisch wrote: > > > Just to add: Virtual PC 2004 SP1 and Virtual PC 2007) were/are available > > as a free download from Microsoft, but didn't/doesn't include any DOS > > version. > > That's true. > > I suspect that the thinking was that if you're running on a PC, then > you already have a PC OS, by definition. This is not true of Mac > users, obviously. Old Windows (e.g. 7) used to let you make a system floppy (using DISKCOPY.DLL, which has a bundled MS EBD disk or whatever). RUFUS will optionally use this if you don't choose FreeDOS. (Yes, RUFUS supports the LiveCD but also has a very minimal FreeDOS bundled already.) I don't think that's available in Windows 10 or newer anymore. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] When is FreeDOS slow and when fast
Hi,
On Sat, Oct 29, 2022 at 2:11 AM Ladislav Lacina wrote:
>
> In the last time I worked a lot with the Freepasval compiler.
> The computer: Pentium 4, SSD PATA disk, 512MB RAM
> The task: Compilation of the full Blocek source ("Build all") - 64603 lines
> of code using FreePascal 3.2.0 (GUI)
>
> FD, cwsdpmi, noUIDE, noLBAcache: 208,2s
> FD, cwsdpmi, noUIDE, LBAcache4096: 54,9s
>
> FD, cwsdpmi, UIDE160, noLBAcache: 72,1s
> FD, cwsdpmi, UIDE160, LBAcache4096: 72,2s - 178,8s
>
> The conclusions:
> 1) The speed without any cache is really awfull. On the speed machine and od
> the SSD disk!
> I do not understand why. Maybe the DOS uses some techniques which are
> contraproductive on SSDs
Cache (and even BUFFERS) takes RAM, which early DOS systems couldn't
spare. Even MS won't partition larger than 32 GB FAT32 drives because
it's slow to access it all in real mode.
> 2) Hdpmi32 does not use the RAM disk swapping while CWSDPMI does
> and it seems to be a reason why it speeds up the things so much.
> I do not understand why CWSDPMI does it even on machine with 512MB RAM.
CWSDPMI shouldn't be swapping at all. It does create an empty swap
file by default, but it doesn't use it until needed. You are using r7
from 2010, right?
CWSDPMI was designed to work on old machines (e.g. his old 386 laptop
with only 512 kb of low RAM), so it put the 4 kb page tables in low
memory, too. (He said this is also hard to debug / fix.) That will
overflow on machines with large amounts of RAM, hence the (default but
optional) r7 feature of using Pentium's 4 MB pages when possible.
HDPMI32 does presumably keep the page tables in extended memory.
If you want to load CWSDPMI resident and try without any swapping, try
"cwsdpmi -p -s-".
It's still better than Causeway, which will swap the *entire* used RAM
out to disk (instead of only how much extra is needed).
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] New version of text editor (and image viewer) Blocek
Hi, On Fri, Oct 28, 2022 at 6:14 AM Eric Auer wrote: > > I noticed that Jim's TRCH only translates one char at a time, > do we already have a variant which is as powerful as Linux "TR", > supporting for example TR 'a-z' 'A-Z' or TR -d '\n' and so on? DJGPP's TextUtils has TR.EXE (but I'm not familiar with it): * http://www.delorie.com/pub/djgpp/current/v2gnu/txt20br3.zip ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Hi, On Tue, Oct 25, 2022 at 10:27 PM Bret Johnson wrote: > > > Although I never truly needed to know what VM > > One of the main things that started me down this rabbit trail was the need to > know which Ethernet card is being virtualized in a particular VM so I can > load the correct packet driver. I have a single ETHERNET.BAT file I run to > install the packet driver, and since detecting which network card is > installed is a tricky proposition I do it indirectly by detecting the VM (or > lack of VM if I'm running on real hardware). I can't remember exactly (would have to check), but I think I just used BERNDPCI.COM. > >> DOSBox > > > > "Only for games". (Maxes out at 64 MB RAM, meh. "Slow Pentium" is > > best it can emulate, IIRC.) > > No, it can run "real" applications also. But you're correct that its primary > focus is compatibility with games. You mean via IMGBOOT or whatever? But that hides the whole guest filesystem aspect. It's still quite limited. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Hi, On Mon, Oct 24, 2022 at 9:07 PM Bret Johnson wrote: > > I've been working on some updates to the ISLOADED program I sent to Jim a few > weeks ago. > Lately I have been specifically trying to add the detection of different > Virtual Machines (including VirtualBox) > to ISLOADED. It turns out that there are a BUNCH of VMs out there that I've > gotten to work with DOS: Jerome's V8Power Tools will detect some VMs, IIRC: * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/v8power.html Although I never truly needed to know what VM, the naive ways to detect (from my limited experience) are a). check DOS version, b). check VESA version string, c). check BIOS string. (You could also check the cpu, but that's messy. DOSBox is a "fast 486" DX2 by default, IIRC.) Actually, I take that back, several pieces of software check for "version 7" and behave differently, which sometimes fails. Like I said, it's naive and imperfect. (Also some like DR-DOS 7.03 report "IBM DOS 6" for compatibility and need their own incompatible version check [int 21h, "DR"] just to know for sure.) > DOSBox "Only for games". (Maxes out at 64 MB RAM, meh. "Slow Pentium" is best it can emulate, IIRC.) > DOSBox-X It's quite interesting (esp. running atop FreeDOS itself). But I haven't tested it too heavily. > DOSEmu / DOSEmu2 Is this available in any repos? I'm very naive. Didn't the original used to be in "multiverse"? I'm not sure it's there anymore. I still haven't tried DOSEMU2 yet, but it uses its own modified FDPP (DOS) kernel, right? It has a PPA or whatever, not sure. (This does supposedly support VT-X now. They used to support other methods, but I'm not sure if that's still supported. Also, they might be 64-bit host only, not sure.) > Hyper-V So Hyper-V does actually support DOS? From what I read (years ago), I wasn't sure. (Back then it was 64-bit Pro VT-X only.) This is also what WSL2 supposedly uses behind the scenes. > JPC The Java one?? > KVM This is just QEMU using VT-X, right? > Parallels Mac? > QEMU I usually just used Stefan Weil's Windows binaries from his site. (I don't remember what version I have installed, probably 6.x on Win7. Latest version of his seems to be 7.1.0.) > vDOS Wengier did some work on VDOSPlus, I thought (for apps, not games, with LFNs and better printing support). > VirtualBox Even VirtualBox dropped 32-bit hosts and non-VT-X cpus a few years ago. (They use OpenWatcom to compile the BIOS.) > There are also a few other VMs out there that I'm not sure will run DOS (the > documentation is unclear > and I haven't been able to install or test them for various reasons): > > BHyve This was created for FreeBSD and first released in 10.0, IIRC. It requires a 2010 Intel (or newer) with VT-X (and EPT). IIRC, they "mostly" wanted to run other versions of BSD, but there was partial effort to get other OSes (even with a BIOS) running. Honestly, I never tried it, but it sounded interesting. (Wasn't the Mac port called xhyve?) * https://wiki.freebsd.org/bhyve * https://bhyve.org/ Apparently it can also run x64 Windows via UEFI. (sysutils/grub2-bhyve is used for running some other *nixes.) > I know the FreeDOS web site also lists several VMs (some of the same ones > I've listed above, > plus JSLinux which is similar to JPC). Not sure, JSLinux is Javascript while (IIRC) JPC Is Java. There used to also be JDOSBox in Java and one guy (I forget) hosts JSDOSBox (Javascript) with demos on his site. There's also 8-Bit Workshop's website, but I don't know what that uses. (There's a lot of fragmentation and old versions). There were also Joris' Retro (Java) and 8086tiny (in C, with various forks). > At least some of the VMs have a "built-in" DOS, often based on some version > of FreeDOS (for example, VPC and DOSEmu). VPC uses FreeDOS?? Not sure. DOSEMU used to allow MS- or DR- or FD-, but I had weakly thought DOSEMU2 required its own FreeDOS fork called FDPP. > Anyway, I'm wondering how "involved" FreeDOS should be in the VM world > (I think in today's world the vast majority of users install DOS under a VM > rather than on real hardware, > though I personally do both). Yes, I agree that VMs are more common for FreeDOS users nowadays, especially with no more BIOS or CSM on new machines. > How involved in testing / recommending applications (including games) > for compatibility should FreeDOS actually be, particularly when a VM is > involved? I would say games are low priority (but still vaguely important) and thus harder to get working. My main interest is in getting old utils and compilers to run. Graphics (and especially sound) are a whole other ball of wax. > Where/how should the results be documented (or if there even should be a > central repository)? You mean like DOSBox's compatibility list? Or WINE? Does WINE still use DOSBox itself? ___ Freedos-devel mailing lis
Re: [Freedos-devel] FreeDOS Interim Build T2210
Hi, On Mon, Oct 17, 2022 at 11:04 AM Jerome Shidel wrote: > > > On Oct 2, 2022, at 5:08 AM, tom ehlert wrote: > > [..] > > btw dowloading 900 MB .zip over a 4MB/s download link is a PITA; this > > alone should recommend a split. (Sorry, I'm horrible at trying to calculate such things, but I try anyways. Corrections welcome.) Is this "megabits"? So that would be 30 minutes, right? 4 Mbps = 0.5 MB per second. So 900 MB would be 1800 seconds ... right?? (Assuming no connection slowdowns.) > Imagine downloading it back when DOS was the main home user OS — over a fast > 56k modem. If you somehow managed to download load it without it erring or > timing out, the next OS release would probably be available when you finished. > > :-) 56 kbps = 7 kb per second, right? So 37 hours?? Seriously, in cases like that, you'd probably just download overnight while you're asleep (and nobody is using the phone). Obviously it's better to only download in pieces so you can verify (with checksum), and retry (if needed), only a small part instead of the whole thing. Some places (e.g. Britain) charge for *local* phone calls, right? So obviously it's more cost effective and easier to just order a physical CD (assuming you have a working drive) or IOMega ZIP disk or whatever. (Or somehow copy it from a friend's hard drive who has a faster connection.) Compression also helps (obviously) but should be done "solid" so that it's not only individually per file (and not in very small chunks like 32 kb Deflate). In other words, 7-Zip is overall superior to most things (in size and speed). (Or maybe RAR.) This also means avoiding redundant files and too many competing versions of the same thing. (Smartlinking helps. But modularity and dynamic libs are a whole other issue.) Actually, back in the day (1997), if you downloaded Allegro for DJGPP, they made you compile it yourself, which (on a slow 486) took 30 minutes. That GCC (2.7.2.1) was tons faster than later versions (even when the latter's optimizations were turned off), don't know why. Maybe it was the small cpu cache (used better by a smaller binary). There are many ways to be frugal in size and speed, but most developers don't have the interest anymore when "everyone" has 64-bit and gigs of RAM. Software is not cheap to develop. These days, hardware is much cheaper than software. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Bonus/Devel CD
Hi, On Sun, Oct 23, 2022 at 1:46 PM Jerome Shidel wrote: > > Although there has not been a lot of feed back on what to do with the > excessively (nearly 1GB) BonusCD in T2210, I think the majority of feedback > has been in favor of splitting off the development packages from the BonusCD > on to their own DevelCD. Yes, probably. I don't have it nearby to look, but a glance at this list ... * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/repos/pkg-html/group-devel.html ... shows a lot of DJGPP stuff. Now, I *love* DJGPP and all it does, but man, is it bloated! That alone takes up the most space, I think. We definitely *don't* need "full" DJGPP here. > And, we should do this instead of dropping packages for several reasons. The > main reason is for the convenience of users who may be on older hardware or > without network support. Those users might experience some difficulty getting > all of the programs they need into their “DOS” machine. Agreed, but you can't please everyone. It's not just DOS support or even "I want C" but dialects and various other minor features. > It has also been suggested to provide a “Developer Oriented” release of > FreeDOS. One that is specifically geared towards DOS development. I actually thought about making my own personal "floppy" for programming! So I know that's not quite what you wanted, but for me, it would be useful: * nasm16 + val, mawk, minised, picoc, P5 Pascal (pcom/pint), dx-forth, regina, dmake, etc. Bundled editor would probably be old SteVIe or e3-16 or even e14_edit. > So where does that leave us? I think there are at least two practical > solutions at present. > > First, split off all development related packages that are on the BonusCD > onto a new DevelCD. This would require very little work. The Release Build > Environment (RBE) is already capable of creating multiple extra package discs > images. However, I will probably want to add some functionality to use > specific labels for them. At present, it would generate BonusCD0 and > BonusCD1. It will not be hard to update the RBE to use custom labels for the > discs. This first solution implies we may eventually have a GamesCD, UtilsCD > and others as well. If we go down this path, perhaps we should start > separating some other packages on to their own media as well. DJGPP could have its own disk. (On my old hard drive, I had at least 1 GB used by DJGPP stuff.) You might also want to include DJGPP-derived things like Free Pascal and FreeBASIC. I mean, I've mentioned before that I made a single 1.44 MB floppy of an old DJGPP (2.03p2 with GCC 2.95.3 + BinUtils 2.16.1 + make 3.79) compressed by 7-Zip (so you only need the small 7zdec). That's C only and lacks C99 and newer GCC features and has no extra graphic or networking libs, but it's much smaller (and can fit on small a RAM disk). Newer GCC is *much* larger. > I don’t know if there is a good solution to this issue. But, I am certain we > can not provide a "950Mb BonusCD.” > > If you have any comments or other suggestions on the problem, please speak up. > > :-) Jerome, you're very smart and have done a ton for FreeDOS, so I trust whatever decision you make here. Don't stress too much over it. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] GNU C Language Intro and Reference Manual
I stumbled upon a link to another cool e-book about C (using the GNU Free Documentation License 1.3): "GNU C Language Intro and Reference Manual" * https://lists.gnu.org/archive/html/info-gnu/2022-09/msg5.html * https://git.savannah.nongnu.org/cgit/c-intro-and-ref.git/tree/ "This manual is intended for learning the C language, if you know how to program in some other language. It is also a reference manual for GNU C. Please report any flaws, including any passage that is unclear or hard to understand." ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Ré : Ré : GCC 12.2.0 and BinUtils 2.35.1 packages
Hi, On Thu, Sep 1, 2022 at 1:10 AM Paul Dufresne via Freedos-devel wrote: > > I said previously: > > Please do not try to install the previous packages for now. > > > > I have created the files in DEVEL\BIN rather than DEVEL\DJGPP\BIN, etc. > > > > Will fix the packages now. > > I think it is fixed now. > Added a package for GCC sources too. > > Again, available at: > https://gitlab.com/dufresnep/freedos-djgpp/-/tree/main I'm pretty sure the sources can only be cross-compiled (obviously??). And you also need MPC, MPFR, etc. (libraries). Sure, it would be nice if these were all reproducible, but I don't think most of us can do it. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] How to install GCC in FreeDOS? (avoid the segmentation fault when running gcc)
Hi, On Mon, Aug 29, 2022 at 1:52 PM Paul Dufresne via Freedos-devel wrote: > > At first I did: > fdnpkg install djgpp_gc > and then tried: gcc , in some directory... was not working > > I then "cd c:\devel\djgpp\bin" > I then "gcc", but then I got a segmentation fault. > > I think that after some Google search (did not help)... I saw > C:\DJGPP\README.1ST > > I then: > fdnpkg install djgpp > fdnpkg install djgpp_bn > > and added to c:\fdauto.bat (after other set, before aliases): > set DJGPP=C:\DEVEL\DJGPP\DJGPP.ENV > set PATH=C:\DEVEL\DJGPP\BIN;%PATH% > ... > reboot > > after that: > gcc --version > have given the expected result. > > Wish to help others get the result faster... either creating a Wiki page > would help. > Or maybe some line written when installing djgpp_gc? Traditionally, you would follow these instructions: * https://www.delorie.com/pub/djgpp/current/v2/readme.1st Also see the mini-FAQ: * http://www.delorie.com/pub/djgpp/mini-faq.txt ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] No simple cpu identification program returning an error code as an answer?
Hi, On Fri, Aug 26, 2022 at 1:27 PM Paul Dufresne via Freedos-devel wrote: > > Following the modification of my idea proposed by Tom: run edit32 on 386+ > else run edit... BTW thanks Tom! I believe CC386 had a 386+ text editor also using D-Flat. > I have been looking a bit for a simple program that would identify > approximate CPU and return it as an error code that batch file could used. > I did not found that (especially with free license)... so that I am thinking > about writing one. > Just asking if that exist already here. Eric Auer wrote this one years ago: * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/cpulevel/ ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] MS-DOS compatibility issue
Hi, On Fri, Jul 29, 2022 at 1:45 PM Steve Nickolas wrote: > > On Fri, 29 Jul 2022, Ralf Quint wrote: > > > But IIRC, the common way to check for the presence of an ANSI device driver >> was to check via an INT 2Fh (multiplexer) call (don't recall the exact call >> value > > (AX/AH)). > > That would only work on MS-DOS 4 or later and I'm not sure NANSI supports > it, but according to RBIL, it's INT2F/AX=1A00, return FF in AL. I remember when Eric Auer added it to NANSI, so it should support it: * https://docs.huihoo.com/help-pc/int-int_2f_0.html INT 2F,0 - DOS Multiplex Interrupt - Get Installed State AL = 00 AH = 1A for ANSI.SYS (DOS 4.0+) on return: AL = 00 not installed, ok to install = 01 not installed, do NOT install = FF installed ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
[Freedos-devel] m2c 0.6 for DJGPP (Modula-2)
Hi all, Years ago, way back in 2013, for whatever dumb reason, I decided to try and build m2c 0.6 (circa 1998) for DJGPP inside DOSEMU. M2c is GPL and supports so-called "PIM dialect" Modula-2 (aka, Wirth's original version). I didn't use it much (except barely for my Befunge-93 interpreter), so I didn't give it much thought until recently. It has some bugs, but overall it "mostly" works. Unlike Pascal, files and strings are relegated to separate external library modules (i.e. usually non-standard). Unfortunately, most (but not all) compilers are PIM and not ISO. You still need DJGPP (gcc), too, so I just used my old fits-on-one-floppy-compressed version (gcc 2.95.3 + binutils 2.16.1 + djdev 2.03p2). * https://en.wikipedia.org/wiki/Modula-2 * https://www.modula2.org/ * https://freepages.modula2.org/ * https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/modula2/m2c/ * https://sites.google.com/site/rugxulo/DJGPP203.7Z?attredirects=0 * https://sites.google.com/site/rugxulo/compilers (sources to GCC et al.) Sorry if the binary .ZIP (m2c.zip) doesn't have proper documentation (check the source archive, it has the man pages and examples). There are several other compilers for DOS, too, but they're harder to find or set up. Much better would be getting GNU gm2 (soon to be part of GCC proper) to build for DJGPP, but I doubt that's going to happen. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] The 386MAX source code has been released :)
Hi, On Sat, Jul 2, 2022 at 4:53 PM Eric Auer wrote: > > PS: Regarding Jim's search and replace suggestion, I like > to add the twist to use "touch" to "copy" the timestamp to > a /tmp/tstamp file, then use sed -i for in-place-edits and > then copy back the change time from the temp tstamp file. I also was going to suggest "sed -i" but, in particular, "sed -i~" (for backup). Also, I believe "touch -r" is what you want for using date from reference file. * https://linux.die.net/man/1/sed * https://linux.die.net/man/1/touch ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] REMember a bug
Hi, On Sun, Jan 9, 2022 at 1:39 AM Jerome Shidel wrote: > > > Since the docs say everything after the REM is ignored, > I feel that the behavior is not consistent with the stated > behavior. So, it is a bug in either the handling of the pipe > in a REM statement. Or, it is a bug in the documentation. > > Either way, It is more of a philosophical question.MS-DOS > is NOT bug free and just because happens in MS-DOS, > does that mean it needs to do the same thing in FreeDOS. > Even if it is a bug in MS-DOS? This is well-known .BAT behavior in MS-DOS (but could still "maybe" be considered a bug). The classic workaround is to use "::" (two colons) to comment out the line, then you can use as many pipes and redirection symbols as desired. ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] Fwd: FDTUI and Minibox
Hi, On Tue, Dec 21, 2021 at 11:29 AM Jim Hall wrote: > > Ercan sent this announcement and question to me, and I wanted to share > it with the freedos-devel list: > > > -- Forwarded message - > From: Ercan Ersoy > Subject: FDTUI and Minibox > > I hve read documnetation on CWSDPMI and have found bug in CWSDPMI. > How can I report for the bug? I'm not sure if it's still considered actively maintained, but you can try here: * https://sandmann.dotster.com/cwsdpmi/knownbug.html ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] SmallerC compiler
Hi, sorry for late reply,
On Sun, Sep 19, 2021 at 6:27 PM Jim Hall wrote:
>
> Smaller C is a simple and small single-pass C compiler, currently
> supporting most of the C language common between C89/ANSI C and C99
> (minus some C89 and plus some C99 features). Currently it generates
> 16-bit and 32-bit 80386+ assembly code for NASM that can then be
> assembled and linked into DOS, Windows, Linux and Mac OS X programs.
>
> The developer recently released a new version. This release includes:
> + DOS binaries (regular and DPMI) + CWSDPMI r5 for the DOS DPMI
> binaries + include and library files + test programs. This release
> also includes the source code, under the BSD 2-clause license.
I'm glad you mirrored this. Maybe I should've pressed harder to mirror
it sooner or done it myself, but I was too busy. (I would've deleted
binaries for other OSes by default, especially because of bogus
antivirus heuristics.) It's truly genius, so I'm glad we have it. I've
already tested it with MetaDOS over the years.
But I never got around to testing this particular release until now. I
always forget everything these days.
It seems fine. The only weird part is the old CWSDPMI r5 from 2000
instead of a newer r5 from either 2002 (three fixes, IIRC) or the 2008
refresh (which also includes the fixes and turns on SSE).
AFAIK, r5 was old and only uses 4 kb pages (e.g. EMS / EMM386 doesn't
know any higher). So the Pentium-era 4 MB pages (much faster but won't
swap, you can also disable it with CWSPARAM) aren't here, only in r7
from 2010. Actually, there's no CWSPARAM included here at all.
I'm dumb, so take what I say with a grain of salt. I'm no systems
engineer. Including this older version may not matter much because it
doesn't use much RAM. (Using any binary in /BINDP/ will also use the
/BINDP/CWSDPMI.EXE binary by default, not any other global one unless
resident in memory.)
But it worries me because r5 would easily overflow the page tables
(which are in low / conventional memory) with higher amounts of RAM, I
thought, e.g. over 512 MB. You can get around it by letting it swap
(default on) to harddisk ("c:\cwsdpmi.swp"). I tried disabling that
(put '\0' where the drive letter is, that's what CWSPARAM does), but
luckily nothing broke. IIRC, Charles said debugging or fixing page
tables wasn't worth it (and he also wanted it to work on very low-end
machines, e.g. an old 386 laptop with only 512 kb RAM!). You can also
change where to swap ("-sg:\whatever.swp") to swap to RAM disk, if
needed, I think, in case it runs out of room for its own page tables
of available RAM. Or use a different DPMI host (e.g. hdpmi32.exe).
Anyways, this is just a ramble from me, trying to clarify. I always
prefer r7 in my testing. I can't think of any reason to prefer the r5
2000 release, but if nothing breaks, it's okay, I suppose. Just be
slightly aware.
* https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/util/system/cwsdpmi/
* https://sandmann.dotster.com/cwsdpmi/
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] DIGPAK sound drivers now open source under MIT license :) Can anybody help me port these from TASM?
Hi,
On Thu, Sep 23, 2021 at 4:55 PM Volkert via Freedos-devel
wrote:
>
> A few months ago, John W. Ratcliff released the sources of most of the DIGPAK
> DOS sound drivers on GitHub.
> He wrote those drivers in the '90s and used to license them commercially
> under the name The Audio Solution.
Good to know, thanks for telling us.
> DIGPAK drivers are used in many DOS games, and provide hardware abstraction
> to software developers through a well-documented INT 66h API.
What specific games used it? If we can find a compatible game that has
sources available, that might increase motivation for some people.
> A few days ago, he clarified the license terms under which he was releasing
> this code. He has chosen to release it under the MIT License.
>
> His repository can be found here: https://github.com/jratcliff63367/oldsource
Cool. (Seems everything is conditionally defined in one large [240 kb]
SHELL.ASM.)
> It would be great if we could include these drivers in the FreeDOS
> distribution, and perhaps also use them as a basis
> for the development of DOS drivers for more modern audio hardware.
>
> Unfortunately, these drivers have been written in TASM Ideal mode dialect. To
> my knowledge, there are currently no open source assemblers
> in existence that can build such sources.
LazyASM (LZASM) was a "freeware" assembler that was TASM compatible
(Ideal only, case sensitive only). I think it was probably a licensed
(Russian?) fork of TASM itself! It's still available on various sites,
e.g. SAC.sk:
* https://www.sac.sk/download/utilprog/lzasmx.zip (DOS .EXE via WDOSX)
* https://www.sac.sk/download/utilprog/lzasm.zip (Win32)
OpenWatcom's WASM has "-zcm=tasm" for partial support.
(I also still have my copy of TASM32 5.3 from 2007's Turbo C++
Explorer. Not sure whether newer Embarcadero C++ demo downloads
include it. Probably!)
I'm far from an expert, but the complexity depends on what features
were used (preprocessor, macros, structs), how much .OBJ or
segmentation support is needed, external dependencies (compilers,
linkers, libraries, include files), etc.
> Would anybody here care to help "fully liberate" these assembly sources by
> porting them to another dialect, such as regular MASM
> (that can be built with WASM or JWASM) or NASM?
JWasm and MASMv6 syntax (see _Art of Assembly_ book) might be a good
candidate. But overall I think NASM is the best assembler to use, for
various reasons. However, it's very imperfect for such old legacy
code.
> I know that VBE/AI is considered a more modern DOS sound API to standardize
> on for DOS driver development, but at least the DIGPAK drivers
> are already out there, and now with sources too. Also, one of the DIGPAK
> drivers in these sources is a wrapper around VBE/AI,
> which would be particularly useful, since it would allow possible future
> VBE/AI drivers to be made to work with many existing games.
>
> I've gained some experience from trying to port the sources of Virtual Sound
> Blaster (VSB) from TASM to other assembly dialects,
> and although I haven't been successful with that, I have gained some
> experience from it. With some help from other more experienced
> assembly coders here, I believe I can be more successful porting these
> drivers.
>
> Who's up for helping me with this? Your help would be greatly appreciated. :)
My experience is fairly low, honestly. Mostly I've just been fiddling
with converting PSR Invaders ("old MASM" syntax) via scripting to
target various assemblers, but it's a simple 8086 .COM, so it's not
too complicated (but hard enough!). So I'm not sure I'm much help.
Anybody truly interested might want to buy Tom Swan's _Mastering Turbo
Assembler_ (2nd ed.) used from Amazon. (I think I checked, and it was
only $16.)
Again, not sure of the overall complexity required here. Legacy code
tends to be VERY myopic.
Good luck! (I'll ask on BTTR to see what they say.)
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] desmet-c link
Hi, On Sun, Sep 19, 2021 at 6:22 PM Jim Hall wrote: > > > On 9/19/2021 1:17 PM, Paul Dufresne via Freedos-devel wrote: > > > On the chat today, desmet-c (that seems to be some kind of fork to > > > https://github.com/IanHarvey/pcc [A small C compiler]). That's not DeSmet C. That's something else entirely (with no DOS port, AFAIK). * http://pcc.ludd.ltu.se/ "The compiler is based on the original Portable C Compiler by S. C. Johnson, written in the late 70's. About 50% of the frontend code and 80% of the backend code has been modified. See the PCC History wiki page for details." * http://pcc.ludd.ltu.se/pcc_history/ * https://en.wikipedia.org/wiki/Portable_C_Compiler The part I remember reading was this (although it's not actively maintained anymore, sadly, AFAIK): "On December 29, 2009, pcc became capable of building a functional x86 OpenBSD kernel image." (But most people in *BSD later went with Clang instead.) There was also a Windows version (using YASM? I can't remember) that I minimally tried, years ago. Not sure if I ever tried it under HX, though. > > > Before closing my tab, mailing the link to all for not loosing it: > > > http://www.desmet-c.com/ > > On Sun, Sep 19, 2021 at 5:49 PM Ralf Quint wrote: > > No, it's not a fork of anything else. It was one of the early PC C > > compilers, a commercial product that due to be produced by a one-man > > company lost out in the market as soon as Borland released Turbo-C... > > > > It's never the less a very interesting and neat C compiler for (Free)DOS... > > Thanks for sharing this. > > So others can find this later, I added a link to the DeSmet C compiler > from the Links page on the website, under "Programming": > > http://www.freedos.org/links/ What you're thinking of is the shareware release of "PCC" found on Simtel here: (from PCC.DOC): "Personal C Compiler" "Copyright 1989 by C Ware Corporation and DeSmet Software" PCC12C.ZIP 175811 Personal C compiler. Fully functional, C WARE * http://cd.textfiles.com/simtel/simtel20/MSDOS/C/.index.html P.S. Don't forget, TinyAsm (aka, minimal NASM clone for 8086 host/target of .COM only) uses DeSmet C to build itself: * https://github.com/nanochess/tinyasm ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
Re: [Freedos-devel] freecom beep crash question
Hi, On Thu, Aug 12, 2021 at 12:43 PM Eric Auer wrote: > > I notice that FreeCOM 0.84pre2 hangs after beeping, probably > because it uses some method for timing the beep which fails > on certain hardware. Could somebody tell me whether newer > FreeCOM versions fix this by using a foolproof timer, for > example the 40:6c timer tick counter? Is there a method to > disable beeping, for example using a command line option? > > Given my habit to use tab-completion in FreeCOM, crashing > after each beep is quite annoying :-p Thanks for your ideas! I guess you've forgotten this old mail from 2016 (May 11, freedos-devel)? "Beep command can't stop sounding when run in Intel Skylelake platorm." [sic] * https://sourceforge.net/p/freedos/mailman/message/35079762/ --- binary patch begins here --- Comparing CMD.OLD and CMD.COM 8293: 55 C3 82AF: 55 C3 ___ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
