Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the board
Thread view  Mix view  Order  «  
 
Steve(R)

Homepage E-mail

US,
15.04.2008, 12:24

@ marcov

Compression

> Let's forget about compression for a minute, and delve deeper into the
> dialup issue.
>
> FPC release zips of the 1.0.x generation where 5MB, currently they are
> 30MB, and only because we forcedly put a break on it. If we were lax they
> would already be 60 MB +.
>
> How long do you think it is responsible to hold everything up, and stop
> packaging new stuff, because a few remaining dialup users are holding you
> hostage ?

Not long. But nobody is holding anybody hostage either. There is still the question, How many users are you willing to leave behind?

> Note that these kinds of reasons are the main reasons why more and more
> large OSS projects are going the netinstaller direction, even though that
> has additional problems too.

Yeah, like if/when your server goes down, all your users will hate you.

Actually, the dialup thing wasn't my main concern, but I'll note a few solutions anyway.

1) Big parts of release packages are old. Build small packages with updates only (actually good for any users).

2) Sell CDs with the full kit. Easy, might make some real money too. Even people who have fast connections can appreciate the time and work they save by not having to burn and test their own CDs.

No need to reinvent wheels - others have considered the issue, and found usable solutions.

marcov(R)

15.04.2008, 15:24

@ Steve

Compression

> Not necessary. 7-Zip's zip/bzip2/gzip compression ratios are very good,
> and formats are all standard.
>
> 7-Zip is released by its author only for Windows. However p7zip has been
> ported to a bunch of platforms - a partial list is at the 7-Zip home site.
> Here are a few more:
>
> Amiga
> http://amiga.sourceforge.net/?sfcontent=/project/showfiles.php?group_id=48010
>
> OS/2
> ftp://weird.da.ru/moveton/
>
> There are also OS/2 file managers that open .7z archives.
>
> And so on.

You don't understand. If you want this, than make sure that this "in theory it should work" really works, and then submit it to FPC. Open source works through own responsibility.

So e.g.
- verify which fpc targets use zip as distribution method. (can be done from makefile)
- verify that the zip unpackers used (including several built-ins) can actually decompress the p7ziped zips. Maybe not all methods are supported. (I'm sure that one had problems with stream zipped ones).
- verify that p7zip works in the build process of said releases, including possible difficult scenario's (network, lfn on all windows and several dos versions) are tested, with the appropriate fixes to the buildsystem etc.

You can submit the patches to the buildsystems (and the chose builds for the relevant platforms) to the bugtracker.

marcov(R)

15.04.2008, 15:43

@ Steve

Compression

> > How long do you think it is responsible to hold everything up, and stop
> > packaging new stuff, because a few remaining dialup users are holding
> you
> > hostage ?
>
> Not long. But nobody is holding anybody hostage either. There is still the
> question, How many users are you willing to leave behind?

Dial-uppers? both of them :-)

Seriously, if it turns out to be a problem, they can turn to distributions on magazine CDs (e.g. the German language area is already covered that way, and nearly any higher educational system has it somewhere anyway (due to Informatics Olympiad using it).

I believe they used to be on sale at some global site too, but haven't checked that in a while, since that is in generally better left to local initiatives (since otherwise postage will be larger than actual costs)

If it then still is a problem, I assume the dial-upers will set up a cut down distribution. But as said, we don't have any indications that it is a problem, otherwise we would have lobbyed cheapbytes and clones more.

> > Note that these kinds of reasons are the main reasons why more and more
> > large OSS projects are going the netinstaller direction, even though
> that
> > has additional problems too.
>
> Yeah, like if/when your server goes down, all your users will hate you.

Not really. Most open source installsystems work with a local dir. This also avoids redownload since you can simply place that on a network share, and all pkgs are versioned, so only new ones are updated. By using http protocol you minimize proxy/firewall problems anyway.

In an emergency network situation you can install entirely from local pkgs, at the small expense of the risk of installing outdated stuff.

See e.g cygwin.

> Actually, the dialup thing wasn't my main concern, but I'll note a few
> solutions anyway.
>
> 1) Big parts of release packages are old. Build small packages with
> updates only (actually good for any users).

But what updates exactly? There is btw also still a public SVN server (when I was on dialup I used CVS mostly too)

> 2) Sell CDs with the full kit. Easy, might make some real money too. Even
> people who have fast connections can appreciate the time and work they
> save by not having to burn and test their own CDs.

See above. That and more already done. We don't want to sell CDs ourselves currently, since there is no webshop knowledge in core. But the main point is that we don't have any indications that this is currently an huge problem.

Rugxulo(R)

Homepage

Usono,
16.04.2008, 01:13
(edited by Rugxulo, 16.04.2008, 01:25)

@ marcov

Compression

> You don't understand. If you want this, than make sure that this "in
> theory it should work" really works, and then submit it to FPC. Open
> source works through own responsibility.

The way you describe it sounds like it's impossible to do anything! And certainly we're only talking hypothetical here, you don't have to do any of this.

> - verify that the zip unpackers used (including several built-ins) can
> actually decompress the p7ziped zips. Maybe not all methods are supported.

7-Zip usually compresses .ZIPs using "Deflate" (i.e. PKZIP 2.x), which is method 8. There's also Deflate64 (which Info-Zip UNZIP 5.5x supports) and Bzip2 (which neither PKZIP/DOS nor Info-Zip currently support ... yet). You have to explicitly tell it to use something other than standard "Deflate" if you want something else. But yes, p7zip .ZIP output is 100% compatible with other tools.

> (I'm sure that one had problems with stream zipped ones).

I'm confused here: "stream zipped" as in "data descriptor" or multi-volume? The former is rare (but used in Java .JAR files) and the latter is unavailable in current Info-Zip tools (though being heavily worked on for the next major release).

PKWARE's APPNOTE 6.3.2 (September 28, 2007)

> - verify that p7zip works in the build process of said releases, including
> possible difficult scenario's (network, lfn on all windows and several dos
> versions) are tested, with the appropriate fixes to the buildsystem etc.

The p7zip compile by DJGPP works fine in DOS and Windows (though I think it's semi-incomplete as some things weren't truly ported, only assumed to work due to no compiler errors: -w requires LFN, and on rare occasion I've had to use "/dev/c/mydir" instead of "c:\mydir" because it didn't accept it (not sure if that's because it got confused by something like C:\ZIP or not).

Also, no idea if it works on network drives, but it does work on all DOSes (with or w/o DOSLFN) and Windows by default (although Win NT needs the NTLFN TSR).

Steve(R)

Homepage E-mail

US,
16.04.2008, 10:54

@ marcov

Compression

> You don't understand. If you want this, than make sure that this "in
> theory it should work" really works, and then submit it to FPC. Open
> source works through own responsibility.

Don't understand what? That it's my job to convince FPC that they should make life easy for more users, and show exactly how? No thanks. The wheel has been invented - if they don't want to roll along that's their choice, which they certainly have the right to make. But there are no purely technical obstacles.

Steve(R)

Homepage E-mail

US,
16.04.2008, 11:32

@ marcov

Compression

> > Not long. But nobody is holding anybody hostage either. There is still
> the
> > question, How many users are you willing to leave behind?
>
> Dial-uppers? both of them :-)

In the US, millions, and for a lot of reasons. How many would get FPC if it were easier? I don't know, and neither do you. So the question stands, How many users are you willing to leave behind?

> Seriously, if it turns out to be a problem, they can turn to distributions
> on magazine CDs (e.g. the German language area is already covered that
> way,

Again, different in the very large US.

> and nearly any higher educational system has it somewhere anyway (due
> to Informatics Olympiad using it).

Fine for students, but which most users are not.

> > Actually, the dialup thing wasn't my main concern, but I'll note a few
> > solutions anyway.
> >
> > 1) Big parts of release packages are old. Build small packages with
> > updates only (actually good for any users).
>
> But what updates exactly?

Small updates that are now held until major release packages can be put together.

> There is btw also still a public SVN server

This is something to put in the webpage. And make binaries, not source only, available. Why should users be required to compile the compiler?

> > 2) Sell CDs with the full kit. Easy, might make some real money too. Even
> > people who have fast connections can appreciate the time and work they
> > save by not having to burn and test their own CDs.
>
> See above. That and more already done.

Also something for the webpage.

> We don't want to sell CDs ourselves
> currently, since there is no webshop knowledge in core.

Making/selling CDs can be outsourced, with info on the FPC webpage - consider, e.g., FreeDOS.

> But the main point is that we don't have any indications that this is
> currently an huge problem.

How could you? That is my point. But you might conduct an experiment - offer CDs for a while, and see if anybody buys them.

marcov(R)

16.04.2008, 16:24

@ Steve

Compression

> > You don't understand. If you want this, than make sure that this "in
> > theory it should work" really works, and then submit it to FPC. Open
> > source works through own responsibility.
>
> Don't understand what? That it's my job to convince FPC that they
> should make life easy for more users,

There is no "fpc" and "users". It is opensource, and all responsibility is shared between all interested parties. As said, it is no priority, and if you want to speed up the priority, the only solution is to put in some work.

> The wheel has been invented

No. To stay in the analogy, it is more that somebody has drawn a rough sketch of a wheel, and then says "the problem is solved", and leaves it to others to implement and fit it under a series of cars.

Reuse of software is often portrait as easy, while it isn't.

> if they don't want to roll along that's their
> choice, which they certainly have the right to make. But there are no
> purely technical obstacles.

How do you know that if you haven't researched it? Is your knowledge of OS/2 and BeOS that well? :-)

Steve(R)

Homepage E-mail

US,
16.04.2008, 21:27

@ marcov

Compression

> There is no "fpc" and "users". It is opensource, and all responsibility is
> shared between all interested parties.

No project really works that way. If everybody is responsible, then nobody is responsible and nothing gets done. But there is a core group that does take real responsibility and makes the serious decisions, like what will be in a package, when it will be released, etc.

> As said, it is no priority,

That's obvious.

> and if you want to speed up the priority, the only solution is to put in some work.

It is not one of my priorities. Sorry.

> > The wheel has been invented
>
> No. To stay in the analogy, it is more that somebody has drawn a rough
> sketch of a wheel, and then says "the problem is solved", and leaves it to
> others to implement and fit it under a series of cars.

A good description of how a large engineering project works, at least in the US - we have a division of labor between design and construction departments.

> Reuse of software is often portrait as easy, while it isn't.

Sometimes it's easy, sometimes it's not. Depends on how a project is organized.

> > if they don't want to roll along that's their
> > choice, which they certainly have the right to make. But there are no
> > purely technical obstacles.
>
> How do you know that if you haven't researched it? Is your knowledge of
> OS/2 and BeOS that well? :-)

OS/2, not too bad. BeOS, forget it - I hardly know what it is.

marcov(R)

16.04.2008, 23:38

@ Steve

Compression

> > There is no "fpc" and "users". It is opensource, and all responsibility
> is
> > shared between all interested parties.
>
> No project really works that way. If everybody is responsible, then nobody
> is responsible and nothing gets done. But there is a core group that does
> take real responsibility and makes the serious decisions, like what will
> be in a package, when it will be released, etc.

True, but those decisions have already been made. Of course compromises and sacrifices are made all the time, but in general the direction is pretty long term.

> > As said, it is no priority,
>
> That's obvious.

Maybe I was a bit rash and brusque, sorry.

It is not really an option now, but a review of the entire packaging and buildsystem is being prepared. The validation of that system could coincide with other postponed changes to the system. But that won't make the upcoming 2.2.2 versions

> > and if you want to speed up the priority, the only solution is to put in
> some work.
>
> It is not one of my priorities. Sorry.

I'm not surprised. OTOH if you don't ask, you'll never get pleasant surprises :-)

> A good description of how a large engineering project works, at least in
> the US - we have a division of labor between design and construction
> departments.

Because corporations are top down. The more grassroots forms of Open Source that FPC belongs too (despite its more centralistic core team model) isn't.

> > Reuse of software is often portrait as easy, while it isn't.
>
> Sometimes it's easy, sometimes it's not. Depends on how a project is
> organized.

There are many sides of it, but the popular blackbox model for external components without many strings or hidden costs is fatally flawed.

And that was what this was about. Research for those hidden costs.

> OS/2, not too bad. BeOS, forget it - I hardly know what it is.

Keep it that way, and forget the former.

Steve(R)

Homepage E-mail

US,
17.04.2008, 12:10

@ marcov

Compression

> Maybe I was a bit rash and brusque, sorry.

No problem - we all get snippy sometimes.

> > A good description of how a large engineering project works, at least
> > in the US - we have a division of labor between design and construction
> > departments.
>
> Because corporations are top down.

True, but not necessarily the reason. It's more a difference between US and European customs, and notions of how many skills one person can be expected to have.

> > OS/2, not too bad. BeOS, forget it - I hardly know what it is.
>
> Keep it that way, and forget the former.

Forget the "better DOS than DOS"? Not yet. :-D

DOS386(R)

01.05.2008, 04:30

@ DOS386

BIG "C" compiler cmp | new facts ore out: OW TCC CC386

Some additional / newer info:

TCC:

+ Very tiny
+ Mostly C99 compatible
+ Low additive bloat
+ No external linker needed

- Seems to have some severe bugs (crashes on it's own source, EBP+xxx vs EBP-xxx gets messed up in some cases ?)
- Additive bloat is low, but code generation very inefficient
- Source badly-hacked to Win32, "of course can compile itself" no longer valid ?

WATCOM:

+ Good DOS support again (except extender so far)
+ LOADPEX support in 1.8 ?
+ Good warnings
+ Less bugs in compiler core
+ Very great JWASM ASAP ? :-)

- Horrible packages (both installers and ZIP's)
- Can't compile itself on DOS
--- DOS version still uses DOG/4SW for both host and target, 13 years after it's death, 8 years after Cause Way was released into Public Domain, and 6 years after PMODE/W and DOS/32A got available !!!

CC386:

+++ Can compile itself on DOS (unique)
+ Inline ASM with NASM syntax
+ ASM output in NASM/FASM syntax
+ Tiny
+ LOADPEX support
+ Comes with VALX and INFOPAD

- Bad warnings
- Severe bugs in compiler core :crying:
- Now not under development

Although it has bugs and is now "dropped" I still highly appreciate it. It has been under development for 10 years, and dropped for 3 months so far. So no final death, nor waste of time.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

01.05.2008, 04:32

@ rr

BIG "C" compiler cmp | DELTREE

rr wrote:

> > 3. Can be deleted easily if someone doesn't like them :clap:
> Did you ever hear about "deltree"?

YES. I know that this thing is supposed to exist ...but I have no idea how to use it :crying: But it's definitely irrelevant here since it obviously won't help you to get rid of all the Registry Crap your D installs on your "DOS" Registry :lol3:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

01.05.2008, 04:41

@ Rugxulo

BIG "C" compiler cmp | the "scientific" facts ore out DW

> You can't (easily?) access the Win32 APIs with it

T.R.N. & Co. should just switch to MinGW, problem vanished :hungry:

> Unavoidable, I guess, unless you want to exclude it (unwise, since XP is
> ubiquitous, at least for now).

Why not, MenuetOS apps don't work "natively" in XP either, and nobody cries :-)

> Not really sure what that means (WLINK bugs fixed?). AFAIK, it has always
> worked on DOS.

IIRC 1.5 didn't.

> > + Comes with WASM, a free "unusable toy" clone of MASM
> Not unusable, but not quite perfect. You can't necessarily expect all your
> old MASM code to assemble without problems.

Obsolete problem :-)

> > + Supports DOS/32A and D3X extender
> The version of DOS/32A included is 7.xx, which is obsolete.

NO. 7.xx is fine besides 9.xx. OTOH complete DOS/32A using the WATCOM design could be considered as obsolete in favor of LOADPEX.

> BTW, OpenWatcom targets .OBJ directly (I think), so you need WDIS to
> convert to assembly source. This is what "OWCC -S" (GCC compiler driver
> clone) does.

OK ... I'll check. Still, direct NASM/FASM output is ways better.

> > - WASM is bad and not really progressing
> That's true, nobody is officially working on it.

No longer. :-)

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

01.05.2008, 04:43

@ Steve

BIG "C" compiler cmp | INTEL

> All Intel compilers for Windows, Linux, Mac:
> http://www.intel.com/cd/software/products/asmo-na/eng/compilers/284132.htm
> BTW, if you want programs to run on AMD CPUs, it's best to avoid Intel

It's best to avoid INTEL since it doesn't run on DOS.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

DOS386(R)

01.05.2008, 04:49

@ Rugxulo

compression / size wars

> need to compress an awful lot of binaries to make room for a handful mp3's.

MP3 sucks :-(

> You can either buy a new HD every year, or you can compress that which is compressible.

Or delete some useless bloat :hungry:

> BTW, DOS' FATs have file size limitations (unlike more "robust" OSes)

NO. Please fix up your facts.

> we're more compelled to optimize for size than otherwise.

YES, but for other reasons.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo(R)

Homepage

Usono,
01.05.2008, 05:27

@ DOS386

BIG "C" compiler cmp | new facts ore out: OW TCC CC386

> TCC:
>
> - Source badly-hacked to Win32, "of course can compile itself" no longer
> valid ?

Right, I tried and failed too. I guess you really need MinGW + MSYS. (If anybody here builds statically and gets it working under HX, please post here!)

> - Horrible packages (both installers and ZIP's)

Well, I'll admit, some of those .ZIPs are really small and have like two (useless by themselves) files. So, I'm not exactly sure why they don't just lump some of them together (e.g. all DOS extenders) into one .ZIP. But I'm not exactly volunteering (yet).

> - Can't compile itself on DOS

A lot of DOS packages don't build on DOS (esp. re: DJGPP). LFN issue? Other?? (How hard is it, really, to support both?)

> --- DOS version still uses DOG/4SW for both host and target, 13
> years after it's death, 8 years after Cause Way was released into Public
> Domain, and 6 years after PMODE/W and DOS/32A got available !!!

I dunno, maybe some tools (\BINW\vi.exe ??) rely on it for some odd reason? (At least, Alt+M reports very inaccurate !negative! numbers with other extenders, at least CWSTUB or DOS/32A.)

DOS386(R)

01.05.2008, 05:30

@ Steve

BIG "C" compiler cmp | the "scientific" facts ore out DW

Steve wrote:

> when are we going to see your compiler? Will you be writing it in FASM?

NO. I won't create a compiler, and at least for you !!! So far you created over 400 posts in 9 months, and I've seen not a single line of code inside them. You posts are 100% troll crap. Just cross-copying announcements, posting stupid "answers" to all my posts (sort of "love" for me ? :-D Did you miss me in last 50 days ? ), and of course generous participation in all famewars. Actually, it's you who is fueling them most :surprised: I should create a compiler for Steve, and then Steve just answers "it's crap", because he can't do differently ? You don't need any compiler, like you don't have and don't use DOS !

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Rugxulo(R)

Homepage

Usono,
01.05.2008, 05:32

@ DOS386

compression / size wars

> > need to compress an awful lot of binaries to make room for a handful
> mp3's.
>
> MP3 sucks :-(

.OGG is more "free", but otherwise isn't nearly as popular.

> > You can either buy a new HD every year, or you can compress that which
> is compressible.
>
> Or delete some useless bloat :hungry:

The only bloat is that which doesn't work or isn't used or useful.

> > BTW, DOS' FATs have file size limitations (unlike more "robust" OSes)
>
> NO. Please fix up your facts.

I assume you refer to FAT+? I meant generic FAT16/FAT32 are inherently somewhat limited. Not a deal breaker, just a known issue.

DOS386(R)

01.05.2008, 05:44

@ Rugxulo

FAT OGG

> .OGG is more "free"

Actually it's Vorbis.

> but otherwise isn't nearly as popular.

But this is a really bad reason to avoid it :clap:

> meant generic FAT16/FAT32 are inherently somewhat limited.

The most famous limits are limits of M$, not limits of FAT. Anyway, I'm developing an idea of a new filesystem removing the FAT weaknesses:

- LFN support but with rules and without hacks
- Volumes 4 KiB...4 PiB with no need of 12/16/32/64 subversions
- No "journalism"
- No 4 GiB file size limit

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Steve(R)

Homepage E-mail

US,
02.05.2008, 00:47

@ DOS386

BIG "C" compiler cmp | the "scientific" facts ore out DW

> Steve wrote:
>
> > when are we going to see your compiler? Will you be writing it in
> FASM?
>
> NO. I won't create a compiler, and at least for you !!!

I'm hurt.

> So far you created over 400 posts in 9 months,

You counted? Now I'm flattered.

> and I've seen not a single line of code inside them.

Can't see what's not there. It doesn't need to be - it's not a requirement for membership in this forum.

> You posts are 100% troll crap.

Now I'm hurt again.

> Just cross-copying announcements,

Is that wrong?

> posting stupid "answers" to all my posts (sort of "love" for me ?

I try my best, sorry if it doesn't meet your intelligence standard. But it is all really because I do love you, and want to help you to be even better than you are.

> Did you miss me in last 50 days ? ), and of course generous participation in
> all famewars.

Absolutely.

> I should create a compiler for Steve,

For the world.

> and then Steve just answers "it's crap", because he can't do differently ?

That's basically your method. Assemblers are crap, editors are crap, compilers are crap...

> You don't need any compiler

You don't know one way or the other. And even if I don't, so what?

> you don't have and don't use DOS !

Wrong on both counts. We've had this discussion before, and repeating your silly claim now doesn't make it any more true than it was earlier.

Steve(R)

Homepage E-mail

US,
02.05.2008, 00:51

@ DOS386

BIG "C" compiler cmp | INTEL

> > BTW, if you want programs to run on AMD CPUs, it's best to avoid Intel
>
> It's best to avoid INTEL since it doesn't run on DOS.

Irrelevant.

rr(R)

Homepage E-mail

Berlin, Germany,
02.05.2008, 16:20

@ DOS386

BIG "C" compiler cmp | DELTREE

> > > 3. Can be deleted easily if someone doesn't like them :clap:
> > Did you ever hear about "deltree"?
>
> YES. I know that this thing is supposed to exist ...but I have no idea how
> to use it :crying:

RTFM or do "deltree /?".

> But it's definitely irrelevant here since it obviously
> won't help you to get rid of all the Registry Crap your
> D installs on your
> "DOS" Registry :lol3:

To write it once again today: What the hell are you talking about?

rr(R)

Homepage E-mail

Berlin, Germany,
02.05.2008, 16:22

@ Steve

BIG "C" compiler cmp | the "scientific" facts ore out DW

> > and then Steve just answers "it's crap", because he can't do
> differently ?
>
> That's basically your method. Assemblers are crap, editors are
> crap, compilers are crap...

You forgot: MP3 is crap. :-p

Steve(R)

Homepage E-mail

US,
03.05.2008, 08:16

@ rr

BIG "C" compiler cmp | the "scientific" facts ore out DW

> > > and then Steve just answers "it's crap", because he can't do
> > differently ?
> >
> > That's basically your method. Assemblers are crap, editors are
> > crap, compilers are crap...
>
> You forgot: MP3 is crap. :-p

You're right, I forgot that one. So let's get everything into the mix, by citing Sturgeon's Law, formulated by Theodore Sturgeon, the sc-fi writer:
90% of science fiction is crap, because 90% of everything is crap.

Rugxulo(R)

Homepage

Usono,
25.07.2008, 06:55

@ marcov

BIG "C" compiler comparison thread

> > > > Many other small compilers, e.g., Aztec C, DeSmet C, Lattice C, LSI
> C,
> > > > Micro C, Microsoft C, Miracle C, Small C, are missing.
> > >
> > > Tendra, TopSpeed/Clarion, Codewarrior, LCC. Iirc LLVM also has a C
> > > frontend?
> > >
> > > btw, there _is_ afaik also a gcc based D.
> >
> > But which of these (besides an older LCC) can run on DOS? (Probably not
> > most.)
>
> Well, that is not the only criterium I think. Produce binaries is another
> one. And then most ld/as based will.
>
> But TopSpeed has a full 16-bit range (C/C++, Pascal, Modula2 iirc) In many
> ways it is nicer than the BP ones, just hard to get by.

Sorry for bumping this thread, but I found a big description of various 16-bit DOS compilers (although it's kinda old). It seems very informative.

http://compilers.iecc.com/comparch/article/91-07-041

Rugxulo(R)

Homepage

Usono,
25.07.2008, 23:15

@ Rugxulo

BIG "C" compiler comparison thread

> Sorry for bumping this thread, but I found a big description of various
> 16-bit DOS compilers (although it's kinda old). It seems very
> informative.
>
> http://compilers.iecc.com/comparch/article/91-07-041

Found two more interesting links (although the latter seems OS/2-related but includes Borland and Watcom, which we all know about):

http://www.itee.uq.edu.au/~csmweb/decompilation/hist-c-pc.html

http://www.edm2.com/0307/compilers.html

Steve(R)

Homepage E-mail

US,
26.07.2008, 00:27

@ Rugxulo

BIG "C" compiler comparison thread

> Found two more interesting links (although the latter seems OS/2-related
> but includes Borland and Watcom, which we all know about):
>
> http://www.itee.uq.edu.au/~csmweb/decompilation/hist-c-pc.html

> http://www.edm2.com/0307/compilers.html

They missed IBM's Cset/2 and C++set/2 - nice compilers, died in the market with OS/2.

Back to the board
Thread view  Mix view  Order  «  
 
15111 Postings in 1359 Threads, 247 registered users, 16 users online (0 registered, 16 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum