Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

FASM lacks OMF/OBJ support (16- / 32-bit) (Announce)

posted by Rugxulo Homepage, Usono, 04.01.2009, 21:26

> And the solution is ? Write a HLL compiler in ASM as reportedly done with
> Virtual PASCAL ? :lol:
Obviously not since marcov says this is unmaintainable (as well as using proprietary crud, which is worse but was probably a sane decision at the time).

> > I addressed whether the OMF object or MZ executable format is required
> for
>
> It isn't absolutely. Just stay below 64 KiB or get around the segmenting
> yourself. ;-)
What was .OBJ originally needed for? Lack of RAM? One-pass assemblers?

> > since 16-bit PM isn't used much
>
> IIRC it never really worked ...
Tell that to OS/2 1.x. (Don't ask me why, but every dumb OS expects everyone to rewrite all their apps. Um, maybe we don't want to? Maybe that's too much trouble? Is a stable API that offensive??)

> While I heavily prefer the latter (ASM) ... that's what makes (in this
> point) CC386 great ... GCC less great (AT&T or "MASM-INTEL") and OW
> "shitty" (no ASM at all :-( )
CC386 uses its own NASM fork, which isn't too far off from GCC's "intel". GCC is 1000x more useful with Intel syntax, we're quite fortunate that they finally implemented it. I guess AT&T is more portable or historic as well as being faster to parse. (Heck, some people prefer writing AT&T style for x86 code for some odd reason.)

And OW isn't bad, directly outputting .OBJ files is probably why it's so fast. (Their "OWCC -S" POSIX compiler driver just uses WDIS.EXE to generate the .ASM anyways.)

Post reply
 

Complete thread:

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