Path: ...!weretis.net!feeder8.news.weretis.net!news.swapon.de!news.mb-net.net!open-news-network.org!news.gegeweb.eu!gegeweb.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: 80386 C compiler
Date: Tue, 26 Nov 2024 13:22:01 -0600
Organization: A noiseless patient Spider
Lines: 126
Message-ID: <vi574u$3j1ud$1@dont-email.me>
References: <vhvbhf$28opb$1@dont-email.me> <vi2rnt$31dba$1@dont-email.me>
 <87ed2zkls2.fsf@nosuchdomain.example.com> <vi34vg$33ql5$1@dont-email.me>
 <87a5dmlsy1.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 26 Nov 2024 20:22:07 +0100 (CET)
Injection-Info: dont-email.me; posting-host="b41e539808bfa9396b994aa453a7865a";
	logging-data="3770317"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+x9NuYbnZaoG4nfbJC7uDq6FDK+5GhgD0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fnE89YuTTl9p6DoqJr+aC4xGYzY=
In-Reply-To: <87a5dmlsy1.fsf@nosuchdomain.example.com>
Content-Language: en-US
Bytes: 6252

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, ...).