Re: 80386 C compiler

On 11/25/2024 6:49 PM, Keith Thompson wrote:

Lynn McGuire <lynnmcguire5@gmail.com> writes:

On 11/25/2024 4:10 PM, Keith Thompson wrote:

Lynn McGuire <lynnmcguire5@gmail.com> writes:

On 11/24/2024 8:00 AM, Paul Edwards wrote:

I have been after a public domain C compiler for decades.

[...]

Did you look at the Open Watcom compilers: C, C++, and F77 ?
     https://openwatcom.org/
>
Open Watcom has many modes of compilation: 8086, 80286, 80386, etc.

Open Watcom's compilers are not public domain, so they don't meet
Paul's (rather odd) requirements.

>
Are you sure about the public domain thing ?  The license is here:
    http://openwatcom.org/ftp/install/license.txt

 Yes, I'm sure that that's a license that imposes some restrictions.
It's not public domain.
 

Skims license...
Yeah, I wouldn't touch that one with a stick...

Just one example:
 """
You must retain and reproduce in all copies of Original Code the copyright
and other proprietary notices and disclaimers of Sybase as they appear in the
Original Code, and keep intact all notices in the Original Code that refer to
this License;
"""
 Anything that's public domain has no copyright.
 

This is one of the "less bad" restrictions in there (it is merely, what most other licenses require).
It isn't really a FOSS license at all.

Why do you ask?
 [...]
 

Looking around, it seems my idea for a "MIT Minus" license already exists in two different variants:
   MIT No Attribution
   BSD Zero Clause
Which do basically let people do whatever with the code, while still providing the protection of a no warranty clause.
I guess it is possible I could consider moving to "MIT No Attribution" for some of my stuff if the normal MIT (Expat) license is seen as asking too much.
But, possibly, oh the terror, some of my past projects had used the LGPL...
My projects still do bundle some GPL code, but it is "OK" as I don't use any of the GPL code in the non GPL parts of the project (it mostly applies to things like the Doom and Quake engines and similar).
Though, they are lacking the WAD and PAK files, as redistributing them is questionable. In theory, the Shareware files could be distributed in an unmodified form, but safer is to omit them.
For my own uses, I was largely using WAD files that were converted to WAD2 mostly so that they could use data compression (mostly LZ4 and/or RP2 in this case; packing tool using whichever gave a smaller file). Functionally, this doesn't change much, but is mostly to make loading times faster (as with program loading, loading in Doom is often IO bound).
Though, Doom does spend a long time doing texture loading during startup with a primarily CPU bound task. Namely, in the WAD file, textures exist as "patch" lumps, and at load time the Doom engine glues them together to build the final wall textures. Not an obvious way to speed it up, can note that id's original response was to display some square brackets and fill it in with a series of dots (eg: "[.......       ]").
The engines retain the ability to load the original IWAD format as well.
Quake didn't originally use or support WAD2 with compressed lumps, but it was provided for in the format. Originally, it specified uncompressed lumps and LZSS (IIRC). I used LZ4 and RP2 instead, as they are both faster and compress better than LZSS (but, back in the 90s, LZSS was fairly popular; taking on a lot of the roles one might now find LZ4 or similar taking on).
Some of this stuff could have theoretically been avoided with filesystem level compression, but this isn't really a thing in FAT32.
Sadly, there is no Wolf3D port, as while I had partially ported Wolf3D, what was lacking was a version of the Wolf3D engine under friendly license terms. I did experimentally also recreate Wolf3D in my modified port of the ROTT engine (also GPL), but couldn't distribute it with data files as, again, I can't legally distribute these (and the original DOS files wont work, things would need to be regenerated using the data files from the Wold3D iOS port, which while available were also not under friendly license terms).
Did partially make a set of "placeholder" assets partly derived from parts scavenged from FreeDoom, but it is pretty far from recapturing the Wolf3D experience (and, likely, someone would also need to make a "legally distinct" stand-in for the Wolf3D levels).
Potentially, I could make a tool to allow expressing maps as ASCII text files, likely as 64x64 grids of characters, with data encoded in the characters. Simple case might be to use a single grid of characters with a translation key (Wolf3D had used 3 planes internally, but a lot of cases are mutually exclusive, like one isn't generally going to be putting entities inside walls, ...).