Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

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

posted by Rugxulo Homepage, Usono, 04.03.2012, 03:34

> I was writing a rather long reply, but my session expired. :( So just
> shortly...
Heh, I had to trim my previous ones because they were over 10000 chars.

> The last change in DJGPP CVS is from 5y ago. It's good there are still
> ports. It keeps it alive. But without any activity in upstream... I don't
> know.
Indeed, it has very very little upstream work being done, mostly just Juan. I'm surprised he's ported so much.

But actually, I'm fairly certain you're wrong. I've seen the posts and am subscribed (heh, why?) to djgpp-workers, so there definitely has been some minor patchwork in the past few months, let alone five years.

Grab djgpp.cvs.tar.gz, gunzip it, then do this: "tar tvf djgpp.cvs.tar.gz | grep 2012- | wc", and it should say 21 lines (aka, at least 21 files changed this year). For 2009, 2010, 2011: 16 lines, 10 lines, 321 lines respectively.

In particular, five days ago Juan posted a patch to djgpp-workers regarding "djgpp/src/libc/posix/sys/stat/xstat.c , which had a previous datestamp of 2001-12-01. ;-)

DJGPP is not dead (yet, barely, close but not quite).

> Re C99. You should know. :P I think the last 7za port in FreeDOS was yours.
I didn't write any new code, just got 4.65 to compile, which was a bit hairy. 9.13 was from Khusraw. Both have the same problem: trying to compile a POSIX (*nix) port atop DOS with DJGPP when the original had heavy Win32-isms in it. There are a lot of "#ifdef _WIN32" in there, which is why some of it doesn't work as well on DOS.

> Btw, that build is case sensitive. Had troubles with it under DosBox. I
> guess it would work flawlessly on real DOS, but... I use DosBox for
> quicktesting to run dos apps directly from right click menu on Linux.
No, it's far from flawless in DOS, it has a few quirks, but it "mostly" works. Or try 7ZA920.ZIP under HX.

> Re owatcom. Wcc(386) is not a big problem. Wlink is. I was thinkng on
> writing a small ld like wrapper around it but I doubt I'll have time for
> it.
The compiler driver (owcc) should mask any calls to that anyways. You normally don't need to call the linker directly. I've often seen makefiles with $(LD) point to "gcc" or "g++".

> I am aware of your mini OWatcom, but haven't played much with it. :) I was
> talking about upstream. ;) Btw, there is also this advice from Rod
> Pemberton:
> http://newsgroups.derkeiler.com/Archive/Comp/comp.os.msdos.djgpp/2005-10/msg00030.html
That depends heavily on target OS, cpu, and memory model. But it's not impossible, just impossible to perhaps please everybody. ;-)

The main problem isn't just ANSI C (1989) but everything since. You can easily have a small compiler if you only stick to strict ANSI, but it's all the extras (C99, POSIX, semi-standard DOS extensions) that add to it.

> Bcc and Desmet were only a sidenotes. They are usable, but not for heavy
> duty porting/development.
Depends on how hard you want to tweak them, how much you want to get your hands dirty, what you want to do, etc.

> Small C was another sidenote. Mainly to counter
> your add of microc to the list. :) I'm pretty sure Dave's MicroC is great,
> but haven't played with it and don't consider it a tool for heavy duty
> porting. :)
Well, it's just a bit quirky and non-standard. Otherwise it's fine. Honestly, unless you really need portability or heavily prefer it, an HLL has nothing over simple assembly. In fact, it might be overkill.

> Re ACK. It's pretty much Unix(tm) specific. But might be possible. Ancient
> backends are pretty much non ANSI compliant or obsolete.

ACK supports ANSI quite well. But yes, I looked again yesterday, the build process is fairly heinous. I wonder sometimes if the time saved using arcane build practices is really worth the pain in trying to make them not break. Sure, it takes longer to build from scratch, but at least you know it will build, unlike trying to configure everything otherwise, ugh. (But this is more of a *nix and C problem.)

> Re ELKS. It had it's own problems. They wanted it to be educational so a
> lot of complex ideas never got their try. And toolchain is base on Minix
> 8086/286 toolchain which had the same limits. It even uses minixfs (which
> is btw great for floppies). To make something out of it, they had to
> improve toolchain. But mainstream developement of bcc stoped. Even Minix
> went with gcc in 386 version.
ELKS is too hard to install and modify, IMHO. But are we really surprised? FreeDOS barely gets any work done, so how can we expect Linux users to care? Most of their code assumes 32-bit ints, they can't be bothered with 16-bit, even with (some) POSIX support. It's just not interesting to them, esp. with the advent of AMD64. It's a lost cause, almost. :-/

I don't know about latest Minix, haven't tried. 3.2.0 was just released. It probably still uses ACK (or at least used to). Presumably it "also" builds with GCC. This is also probably because of the BSD-ish license, but who knows. Yes, it seems 3.2.0 is borrowing heavily from NetBSD.

> So bcc got hardly any developemnt beside what
> Robert de Bath was doing. Bcc also limits the size of kernel, which makes
> it tough to add enough device drivers. They did a sample implementation(s)
> of loadable module drivers but it collided with swap implementation. The
> other problem is limited support for 386+ and no pm support. DOS use
> extenders for this. One of ideas they were toying in the past was making
> kind of loadable drivers like in DOS. But nothing got out from this idea.
The typical "solution" you'll hear to such problems is just ignore it. "Nobody" (they say) sells or makes or uses less than 386 / 32-bit anyways, so it's not worth doing.

Personally, I think that's a copout. But yeah, it's hard to talk to some people. It's kind of a weird pissing contest in some ways, everyone wants to show up someone else.

> Offtopic I was playing with wcc and djgpp for a several days now (mostly
> Thomas Dickey's stuff, including a newer version of byacc then in Freedos).
> What is best way to put that stuff for test. A new topic? I am afraid it's
> nothing compared to the stuff you guys do, but it might be usefull to
> someone. Yes, I'm a lamer. :)
There is a DJGPP port of BYacc, but I'm not heavily familiar with it (or "yacc" in general).

You're not a lamer, or at least no more than I am. I'm seriously wimpy in coding skills, just a lame hacker, doing lots of ad hoc stuff with little planning. It's hard to do something at all, much less well or portable or robust. Don't think everybody else is so super smart, they aren't. They're just heavy specialized. Nobody knows everything.

As for kicking the tires, dunno. The only things that I know of that might? be easy to build and need Yacc are GNU Bash (also needs m4) or Detlef's LCC/DJ. But to just play with DJGPP, you can choose anything. The TDE editor compiles very easily with it. And OpenWatcom has its own vi editor, even for DOS. Heck, Thomas Dickey's VILE compiles with DJGPP too. Unfortunately, OW has less support for (common Linux-y) POSIX code than DJGPP. Just find something you're interested in (hopefully with sane build process and requirements) and see what you can make of it. And ask questions (somewhere, anywhere) if needed.

Post reply
 

Complete thread:

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