Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Old 8086 version of pcc spotted (cross-compiles to DOS) (Miscellaneous)

posted by Rugxulo(R) Homepage, Usono, 01.03.2012, 21:36

> I guess it was mostly meant to be a crosscompiling toolset for ELKS.
> The limitations are the limitations of the original executable format bcc
> was orignally written for (Minix a.out format).

Yes, it's mostly known for ELKS. I don't know of anyone else using it very much, outside of what little Linux 386 kernel bootstrapping is (apparently) done. Oh, and maybe? DOSEMU uses it at build time.

> I think this (DOS version)
> was ported by Robert de Bath. Most of the updates are to boot loader
> generation code (he still maintains dev86). This is what dev86 is
> mostly used on *nix platforms these days.

I think he compiled the DOS-hosted version with MS C, but 0.16.2 was a while ago, latest is 0.16.18.

> Anyway I don't know how complete is DOS C library. But it comes with a
> small elks "emulator" to run elks binaries natively. This *might* be used
> as a stub to port old *nix software, but haven't tried. At least not under
> DOS. I think I managed to make something similar for Linux some time ago
> (compiled elks app with stub merged in).

It's missing gettimeofday(), for instance. Other stuff seems mostly there. I haven't checked too closely. I don't think it's quite ANSI C, but it's fairly good anyways (surprisingly).

Yes, (Linux 386) elksemu and doselks.com exist, and I've tried them both. They work. Granted, it's not 100%, but it's fairly good. But don't expect any miracles, i.e. ELKS supports LFNs and fork() which DOS doesn't.

> Btw, it seems ELKS is revived in past several weeks. No new features or
> anything, just bug fixes and general code cleanup. I think this is still
> only available from git. So, if you played with it earlier, check out the
> mailing list or git repository. :)

No, I never barely played with it. I think I even had a hard time booting it up and transferring files. I may have just used some Minix fs tools. Kinda sad that ELKS is so abandoned, worse than FreeDOS even! But yeah, not a lot of 16-bit cpu users these days.

> Btw, I don't have any connection to ELKS and haven't contributed any code.

Ditto.

> I did try porting some C applications (mostly usenet sources and some
> embedded utilities) with varying success. IE, 8086 version of libc doesn't
> have math (8087 or emulation) library implemented. A lot of stuff won't
> work without math library. For example, lua 1.0 seems to compile ok, but
> can't be linked because of the absence of -lm. And C library is not
> standardized anyway.

Don't know, never tried compiling anything heavy-duty. I think it lacks unsigned char and has other weird restrictions. It's probably mostly K&R with a bit of ANSI tacked on after-the-fact, e.g. "-ansi" calls unproto to convert to old-style form for the compiler proper.

> ELKS doesn't have stable API. So if you can't hack on
> as86 (at&t syntax, uses int 80h for system calls like linux), you're much
> out of luck on extending it.

Yeah, I'm not familiar with its asm syntax. I've barely messed with it, only a little out of curiosity / comparison.

> > Well, admittedly, there's less of a need to port PCC because DJGPP and
> > OpenWatcom already exist. And while their DOS support isn't very active
> > these days, they're already pretty robust and bug-free. (But yeah, GCC
> uses
> > lots of RAM these days, sadly.)
>
> Well, yes. But...
>
> DJGPP C library haven't been touched since 2003. Only updates come frome
> libsupp. But nothing official.

CVS version is still updated, even recently, but no, there's been no "official" release since 2003 (2.04 "beta"). 2.04 wasn't nearly as tested in multiple environments as 2.03p2. And it added some questionable stuff that needs peer review (or so I'm told). It's mostly better, though, e.g. symlinks and 4 GB file support (not that FreeDOS supports that, meh).

There has been no release manager with 2.04 beta to see it finalized. I think the last one was Andrew Cottrell (sp?), who's long since AWOL. CWS himself only hacked it to get it working on Win2k/XP, and once that worked he lost interest (though in the past two or three years he's shown some minor interest in getting it "out the door" ... eventually).

There are some people who only use 2.03p2 "stable", e.g. Eli Z., so perhaps there is some minor resistance there. Like I said, it supposedly was tested in all kinds of environments (e.g. native DOS) while 2.04 was mostly only tested in XP.

> Ports can be a little hacky and not stable.

They work fine, but it's always a pain to bootstrap, so they long ago gave up on building in 8.3 SFN. The ports work, but you have to keep in mind the horrible horrible kludges they have to do because POSIX (ahem, Linux) code is so annoying. Keep in mind that GNU only cares for POSIX, nothing else, so it's an uphill battle, to say the least.

> They are mostly crosscompiled nowadays. Or compiled under Windows. No or
> very little native developement. I tried using gcc 4.6 with djdev 2.03
> libs, but had better luck with GCC 3.3.6. It's still modern enough (at
> least C backend) and supports some of C99. So most stuff compiles ok. GCC
> 3.3.6 port seems much less memory intensive and stable. The other ports are
> of varying quality. For example bash port is pretty much buggy.

I think GCC 3.4.4 (2005) was most stable, but 4.1.2, 4.2.3, 4.3.2, 4.4.5, 4.6.2 are good too. None is perfect, believe it or not. C99 is less crucial, IMO, but some projects do use it, so I wouldn't go below 3.2.3. Similarly for decent C++ support, even some require /backwards/ headers last found in 4.2.3.

I just wish it wasn't so slow and bloated. Worse than any of that is the (relatively) high memory requirements these days, which boggles the mind. But hey, beggars can't be choosers.

Yes, Bash is buggy, but you need it for the (God-awful) ./configure abomination.

> OpenWatcom, on the other side, is still dependent on DOS4GW and includes
> some proprietary elements.

You don't need it for 99% of stuff.

> Yes, there is also DOS32A but it often crashes dosemu and dosbox.

Are you using DOS/32A 9.1.2 or only (old) 7.2 included with OW? (I don't know why they never upgraded.) Also keep in mind that neither native DOS, DOSEMU, nor DOSBox are flawless, they all have issues (ironically).

> Most of OW binaries depend on DOS4GW and toolchain is
> maybe too large. It would be nice to have a small toolchain without misc
> utilites and crosscompilers/installer. Only the basic libs and toolchain.

I made a floppy-sized .7z of the compiler with only the 16-bit DOS targets.

ow13-286.7z
ow17a286.7z

So you can slim it down, if necessary. (I didn't bother with 386-only because that seemed redundant to DJGPP, IMO.)

Also, see the "DOS-only" OW 1.9 .7z, it's only 7 MB: FreeDOS / iBiblio / devel / c / openwatcom

> On the other side, I'm so used to unix C toolchains I can't get around to
> use wlink, or even wmake or wcc sometimes. But it does seem to be more
> stable than DJGPP GNU ports and it has pretty ok C lib. And it has 16-bit
> backend.

No LFN support, at least not by default, and even optionally it's only half-finished. So that's a (very minor) drag. Also lacks a lot of POSIX stuff. Keep in mind that I don't personally care, but stupid Linux / GNU only codes (heavily) for POSIX.

But yes, OW is awesome. But admittedly wmake isn't totally compatible with GNU make. If you miss *nix toolsets, try the OWCC.EXE compiler driver, it tries to mimic them for easier use.

> And both toolchains have a hacky implementations of dlls.

DJGPP 2.03p2 only has (very weak) DXE1. 2.04 has DXE3, which is better. DJELF has full .so support. Japheth hacked DJGPP 2.03 to produce DOS-only PE/DLLs with DJGPP libc. OpenWatcom's Causeway/DOS supports .DLLs too. And that's ignoring HX's support (emulation?) of Win32 PEs w/ .DLLs.

> > Desmet C is too minimal, it definitely doesn't have full ANSI libs. But
> > it's okay, I guess, and certainly easier to modify or bootstrap than
> > others. The only problem is (IMHO) trying to decide which .ZIP to
> download
> > from the website. Apparently the guy had several versions and never
> > finished cleaning up any of them. Also some are more complete than
> others.
>
> I think I looked at the source some time ago. I think it was hell to even
> look at it. :-|

I don't know what that means. I didn't look too closely. I just know it was much much much smaller and simpler to build vs. GCC (abomination).

> But I don't how much it conforms with ANSI. He didn't update the page for
> years so it's hard to know if he made some success with it.

Yes, it had ANSI support, but the libc was fairly lacking. It didn't have a lot of things ANSI assumes (e.g. 15 .h files).

> I didn't play with it much though. Yes, it seems minimal, but that might be
> interesting for legacy purposes where small size is of concern. Btw, it
> seems to have 8086-80386 support in later versions.

I doubt the 386 support is very good, but I didn't check. There was also a third-party optimizer, but I didn't try it. Again, it's indeed hard to know which version is "recommended" as he never finished and had so many versions online. And it's clearly not robust enough to build the FreeDOS kernel (nor is BCC/Dev86), at least not without major tweaking.

 

Complete thread:

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