Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Smaller C compiler (tests under emulation) (Announce)

posted by alexfru(R), USA, 10.05.2015, 00:25

> > I do have my own tools to create a FAT12-formatted floppy and populate
> > it with files. But the idea of writing DOS batch files for this is
> > putting me off. :)
>
> What's the problem with .BATs? Too tedious? Anyways, I'm starting to wonder
> if makefiles (e.g. 16-bit port of Dmake) would be better (for testing).

.BATs are a bit too primitive to my taste and insufficiently standardized/
widespread. I wouldn't be able to use them under Linux, for example.
They'd have to be confined to DOS/Windows environment. Makefiles aren't
the best either. There are different makes and Windows doesn't provide
make out of the box.

> > Is the last commercial version of Watcom (10.x/11.x?) less buggy,
> > do you know? After all, it was Watcom with which a bunch of popular
> > games for DOS (e.g. Doom, Descent, etc) were compiled.
>
> I'm no expert, but I think those ancient versions are even worse. Even OW
> 1.4 (or 1.8) added and fixed lots of stuff. If anything, newer versions are
> probably regression-tested better than ever.

The kinds of bugs I've found in OW (and heard others stumble upon)
suggest that testing in OW is rather poor if existent at all. The OW's
very own website says that 3rd party commercial tests were lost in
transition of the project to open source. They couldn't be open sourced.

> > > Did any of this help? I feel like I just mostly rambled (again, sigh).
> >
> > Not really/not yet. :)
>
> I honestly don't know what you're trying to do here.

What do you mean by that?

> Sounds good. Though I'm not sure what advantages PKLITE has over UPX.

Probably none. Think of it as a recognizable brand name rather than
a specific .exe compressor.

> The problem with FASM (for 16-bit DOS target) is lack of OMF/OBJ support.

It is a problem to a degree. OMF/OBJ itself is a huge problem. It's an
overly complicated format that pretty much nobody implemented properly.
We may talk about conspiracy theories behind different OMF/OBJ tools
being incompatible with one another, but it's a too big and too quirky
thing to deal with.

My compiler's linker consumes ELF32 object files, no matter if it's 32-bit
code for Linux or for Windows or 16-bit code for DOS. NASM supports
16-bit relocations in ELF32 and that's all that's really needed.
Segments can be organized around that, if needed.

> And the problem with FreeDOS' kernel is reliance on quasi-standard 16-bit
> DOS-isms and (now) compact model.

Yeah, far pointers and such peering out of every corner. :)

 

Complete thread:

Back to the forum
Board view  Mix view
15192 Postings in 1365 Threads, 250 registered users, 9 users online (0 registered, 9 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum