Hi, sorry for late reply,
On Sun, Sep 19, 2021 at 6:27 PM Jim Hall <jh...@freedos.org> 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
