One cool thing about the UXN DOS port, even tho it's taking me forever...

It's very much challenging assumptions I had about OpenWatcom. I will have to make a repo of test cases for diagnosing bugs later.

Speaking of which @neauoire, I have ASMA working in DOS. I think I want to iron out the libc bugs in PCUXN before I start testing on my IBM PC and PC AT, however.

@neauoire I don't have a VGA card attached to an old PC- only EGA and Hercules monochrome.

Okay, that's not quite right. I have a second IBM PC motherboard for hardware hacking and testing, and _that_ has a VGA card.

So I can at least try it to see how it works from real DOS.

@neauoire Didn't think about that, but same result when I feed DRIF2.TAL with LF line endings.

But... DOS libc may be adding CR to LF when reading (although IIRC the DOS API never will do such bullshit). Not sure...

@neauoire Uncertain, as drifblim crashes DOSBOX right now :P.

Possible explanation follows in next toot.

@neauoire
Things I've learned about my DOS C compiler that I legitimately didn't know before starting this port:

1. calloc(65536, 1), or even calloc(65535, 1) doesn't work. I used calloc(0xff80, 1) as a workaround, but I will be changing that to a static 65536 array in PCUXN (DRIFBLIM crash?).

2. <dirent.h> => <direct.h>. No, I don't know either.

3. opendir() succeeds on files (the f***?!). I will need to replace with _dos_findfirst, etc.

@neauoire (DOS libc fread, open, opendir, etc wrap the DOS API provided by int 0x21.

The source code to my libc is on GH, so I can check what it does before and after calling the DOS API, but not convenient to do it right now :P.)

@neauoire Ahhh okay. And yea, I can't calloc 0x10000 for a DOS app. Idk if it's a DOS limit or libc limit.

My impression before tonight was "you can get 640kB if you do several 0x10000 byte allocations", but I need to examine further.

Related: Well, as long as you're okay at me working at my own pace (yes I know I'm slow getting back to you lately :P), I can look into such a file test.

I want answers from my libc first tho :P.

@neauoire Fun DOS Fact For The Night (No Refunds If Not Fun):

DOS _does_ have a dynamic allocation call in its API, but what most apps do, including OpenWatcom C binaries _IIRC_, is "put in the EXE header to just reserve all available memory".

Meaning malloc/calloc is morally equivalent to "allocate from a fixed buffer on the user side".

@tek Rust isn't portable enough for me to completely abandon C (add backends besides LLVM and GCC- maybe something targeting SDCC, for instance- and then we'll talk). But sadly, to most ppl, the only two archs that exist are x86 and ARM :/.

But if my Rust portability gripes were fixed, I still think Rust is too complex a language to be the "minimal viable no-GC programming language".

You can't write safe C, but C is still simple enough that a single person can write a crappy compiler.

@tek Not to get on my bootstrapping rant again, but I haven't seen any indication that a Rust compiler as exists today is actually implementable in a language less powerful/complicated than Rust.

I.e. there's just too much code to write that only a language with lots of features- with a compiler that would take a lot of time to write- can offset the cognitive bandwidth required to impl a Rust compiler. Also applies to C++. Even mrustc is written in C++.

And that scares me.