DOS ain't dead

http://members.tripod.com/~ladsoft/

All CC386 3.74 files are up. Some other files too, but not the whole of the former site.

Ladsoft writes:

> However, this is also to give anyone who wants it the chance to archive the
> projects, make them available elsewhere or do further work on them.

This is the time now to host GRDB and - at least - VALX here on BTTR!

(CC386 is not that important IMO since OW's WCC386 is better)

---
MS-DOS forever!

> This is the time now to host GRDB and - at least - VALX here on BTTR!

Rely on "DOS386" and you are lost. I contacted David myself a few days ago and I resurrected parts of his home page. I'll put those files up in "a few days".

---
Forum admin

> Rely on "DOS386" and you are lost.

Yes, DOS386 is talking a lot. But he can make good screen shots.

> I contacted David myself a few days
> ago and I resurrected parts of his home page. I'll put those files up in "a
> few days".

Thanks! If I can help in any way, please let me know!

---
MS-DOS forever!

> This is the time now to host GRDB and - at least - VALX here on BTTR!
>
> (CC386 is not that important IMO since OW's WCC386 is better)

I think the stand-alone VALX is probably older than the one included in CC386. Also, remember that CC386 is only like a 2 MB download (DOS version) vs. much more required for other DOS compilers. And it uses a custom NASM as a backend. Granted, you could make a lite OpenWatcom that would only be like 4 MB compressed (11 MB unpacked), and yes, OpenWatcom probably optimizes better (since CC386 isn't really optimizing ... that was one of Ladsoft's goals to fix that, oh well). Still, DJGPP/GCC 4.2.3 is slightly better at optimizing than OpenWatcom even (but requires more memory to compile, at least with -O2).

GRDB, ironically, needs TASM (but a MASM makefile is also included) to reassemble. OpenWatcom's WASM will assemble some (but definitely not all) of the source files for GRDB. I tried "for fun" with WASM recently, and wasn't too disappointed that it didn't work.

> CC386. Also, remember that CC386 is only like a 2 MB download (DOS
> version) vs. much more required for other DOS compilers. And it uses a
> custom NASM as a backend. Granted, you could make a lite OpenWatcom
> that would only be like 4 MB compressed (11 MB unpacked), and yes,
> OpenWatcom probably optimizes better

Besides speed (which is not that important IMO) is that OW supports C++. Also, they improved the CRT concerning size. A simple 32bit DOS "hello world" binary with OW is now just 17 kB.

> Still,
> DJGPP/GCC 4.2.3 is slightly better at optimizing than OpenWatcom even (but
> requires more memory to compile, at least with -O2).

DGPJJ's disadvantage is its non-zerobased memory model. And the binaries are bloated. And WD is better than GDB. I prefer OW. IMO since OW exists there's no reason anymore to use DGPJJ at all.

> GRDB, ironically, needs TASM (but a MASM makefile is also included) to
> reassemble. OpenWatcom's WASM will assemble some (but definitely not all)
> of the source files for GRDB. I tried "for fun" with WASM
> recently,
> and wasn't too disappointed that it didn't work.

WASM is a toy. I thought you know that. (Still better than ASS of course)

---
MS-DOS forever!

> DGPJJ's disadvantage is its non-zerobased memory model. And the binaries

DGwhat?
I think a non-zero based memory model is no problem for most apps. It will only become a problem when you do low-level stuff.

> are bloated. And WD is better than GDB. I prefer OW. IMO since OW exists

I agree. DJGPP binaries are heavily bloated.

> there's no reason anymore to use DGPJJ at all.

The DJGPP repository holds a lot of common GNU tools. Try to convert all these to OW first, before you drop DJGPP.

---
Forum admin

Non zero-based model makes DLL like stuff very problematic. There is no good way how to make some dynamic loaded libraries with it.

---
DOS-u-akbar!

> good way how to make some dynamic loaded libraries with it.

Have somebody tried the new version of mplayer? it should be able to load dll-files. So it is possible

Btw: Maybe the code is very big - pero DJGPP has many many features. One ist, that many tools can be easily ported from Linux to DOS, it is heavily under developement (gcc/g++) etc. It makes the life much easier, without DJGPP DOS would be dead now!

> Non zero-based model makes DLL like stuff very problematic. There is no
> good way how to make some dynamic loaded libraries with it.

Most DOS people don't need DLLs.

---
Forum admin

> > Non zero-based model makes DLL like stuff very problematic. There is no
> > good way how to make some dynamic loaded libraries with it.
>
> Most DOS people don't need DLLs.

Not now - but maybe in the future? btw. mpxplay is using dlls, mplayer too... could be very useful in the future.

DJGPP has by far the best and up-to-date library support from all the DOS compiler packages. DXE3 is OK for DLLs, but if 0 based model and loadable modules are needed, one can use Daniel Borca's ELF port. It's sad that DLLs are so scarcely used in DOS. That's why complex programs are so fat, because the libraries are staticaly linked. What would be if e. g. allegro.dll is loaded by all programs which use allegro instead of having a copy of allegro in each of them?

> It makes the life much easier, without DJGPP DOS would be dead now!

You're a student, so you should have some faint idea what science is. So please provide some scientific evidence for your claims! I have some doubts, because I'm unable to see how DGPJJ has made *my* life easier.

However, it doesn't matter what DGPJJ has "done" in the past. What's relevant is if it is *still* the best choice for a DOS compiler. IMO: No.

---
MS-DOS forever!

> What would be if e. g.
> allegro.dll is loaded by all programs which use allegro instead of having
> a copy of allegro in each of them?

Hehe, and then you will run into troubles with incopatabilities between various progs compiled for different alegro versions like is common under windows and you then will need to provide your alegro.dll working with your prog to be sure it will works for others...

---
DOS gives me freedom to unlimited HW access.

> However, it doesn't matter what DGPJJ has "done" in the past. What's
> relevant is if it is *still* the best choice for a DOS compiler. IMO: No.

I didn' studied it but how much is OW compatible with GCC? I'm happy that my sources (C + inlined asm) can be compiled under djgpp, mingw32, linux-gcc and sometimes also avr-gcc or arm-gcc without changes (of course except low-level hw dependent stuffs). Also djgpp can already use something like DLL - a DXE dynamically loadable modules but I tried it only once and didn't need to use it.
I agree that DJGPP exe's are greater than others but I think it's due to posix enverinment inside.

---
DOS gives me freedom to unlimited HW access.

> Hehe, and then you will run into troubles with incopatabilities between
> various progs compiled for different alegro versions like is common under
> windows and you then will need to provide your alegro.dll working with
> your prog to be sure it will works for others...

It's a good practice for libraries to be backward compatible even if new features are implemented. I prefer to have one reusable dll than to bloat the executables with the same code again and again.

> Hehe, and then you will run into troubles with incopatabilities between
> various progs compiled for different alegro versions like is common under
> windows and you then will need to provide your alegro.dll working with
> your prog to be sure it will works for others...

And then the program can't use smart-linking to weed out all the unused Allegro functions, and the application/run-time is even bigger than it would have been if allegro had been statically linked in the first place. And you still have to deal with all the version issues.

Application-side DLL's are generally a bad thing IMO.

> It's a good practice for libraries to be backward compatible even if new
> features are implemented.

I know, that it should be but often doesn't. Look at your win directory and see how many dll versions of the same is there, e.g. vbrunxxx.dll, msvcrtx.dll and
the d3dxxxx.dll from latest DX9 with updates is the extreme...

> I prefer to have one reusable dll than to bloat
> the executables with the same code again and again.

If allegro would have smaller module granularity (more smaller .o files in library) then it probably will produce smaller EXE because linker will not link all unused .o when no function(s) are referended there.

---
DOS gives me freedom to unlimited HW access.

> Besides speed (which is not that important IMO) is that OW supports C++.
> Also, they improved the CRT concerning size. A simple 32bit DOS "hello
> world" binary with OW is now just 17 kB.

OpenWatcom supports C++, but their support is not nearly as modern / standard as DJGPP / G++.

BTW, that 17k .EXE, is that from 1.8 beta? Does that include DOS extender or just the DOS/4GW stub? Is that before or after UPXing?

> DGPJJ's disadvantage is its non-zerobased memory model. And the binaries
> are bloated. And WD is better than GDB. I prefer OW. IMO since OW exists
> there's no reason anymore to use DGPJJ at all.

DJGPP handles LFNs unlike OpenWatcom for DOS. (But yes, Win32 .EXEs via HXRT could use LFNs). Also, response files, cmdline globbing, long cmdlines, symlinks (2.04), DXEs (e.g. FPU emulation), among other things.

> WASM is a toy. I thought you know that. (Still better than ASS of
> course)

You mean GNU as? Yeah, I dunno why anybody bothers using that as a stand-alone assembler in lieu of YASM, NASM, FASM, etc. The only advantage, as I've said before, would be its ubiquity, but even NASM is pretty much everywhere now. (I mean, most Linux distros have a billion packages, so it is really that big a deal to assume NASM too??)

> I agree. DJGPP binaries are heavily bloated.

No, they aren't bloated, but they aren't as small as they could be. I've never been able to recompile the LIBC.A (tried yet again yesterday, unsuccessfully), but using -Os would probably help a little. (Most stuff seems to be compiled using -O2, which isn't totally optimal for size.) There is no "one size fits all" here.

You can always disable cmdline globbing, arg parsing, and/or env. file loading if you want extra space (see CRT0.H). And don't forget UPX. (But yes, 2.04 binaries are noticably a tiny bit bigger, symlink support?? I dunno ....)

> The DJGPP repository holds a lot of common GNU tools. Try to convert all
> these to OW first, before you drop DJGPP.

If only *nix people weren't so obsessed with using obscure features in the ultra-super-modern latest version of MAKE/BASH/etc. which makes ports so much harder!

> > It makes the life much easier, without DJGPP DOS would be dead now!
>
> You're a student, so you should have some faint idea what science is. So
> please provide some scientific evidence for your claims! I have some
> doubts, because I'm unable to see how DGPJJ has made *my* life easier.

TDE, VIM, FED, FTE, VILE, GZIP, BZIP2, DOSFSCK, FreeBASIC, FreePascal, Ghostscript, Quake, LAME, NASM, NDISASM, JASSPA MicroEmacs, SBC, MAME, Doom Legacy, Ardi's Executor, YASM, UPX, XPDF, Dungeon Crawl, ADOM, NetHack, Perl, Python, Ruby, Unrar, p7zip, Info-ZIP's ZIP + UNZIP, LHA/Unix, LZOP, AdvanceComp, bash, GNU find, GNU tar, GNU sed, GNU awk, GNU grep, BIEW, DJTAR, etc. etc. etc.

> However, it doesn't matter what DGPJJ has "done" in the past. What's
> relevant is if it is *still* the best choice for a DOS compiler. IMO: No.

There's no doubt that HX + OpenWatcom is a formidable toolset. But I don't think GCC is outdated by any means (slightly better optimizations). Both have their uses, and both are free, so why not use both?

> It's a good practice for libraries to be backward compatible even if new
> features are implemented. I prefer to have one reusable dll than to bloat
> the executables with the same code again and again.

I think there are issues with having more than one Cygwin .DLL residing on your computer. So that's a good argument against that. (Seriously, I wish most programmers would provide prebuilt static and dynamic binaries!)

> Rely on "DOS386" and you are lost.

Either I'm failing to see the point of this post or there is none

I also see no reason to panic - CC386 is not under development by now, but hey, some people still use proprietary buggy 20 years old compilers

CC386 3.72 is mirrored here:

http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/cc386/372/

Now the 3.74 files are back online, and if they vanish one day, I can upload them from my backup somewhere then

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

> > Besides speed (which is not that important IMO) is that OW supports C++.
> > Also, they improved the CRT concerning size. A simple 32bit DOS "hello
> > world" binary with OW is now just 17 kB.

It's good that OW DOS support is improving Competition is nice (at least as long as it follows useful goals)

What's this 17 KiB ? DOS LE ? DOS LE + STUB32A ?

> BTW, that 17k .EXE, is that from 1.8 beta? Does that include DOS extender
> or just the DOS/4GW stub?

IIRC the DOG/4SW stub has 12 KiB - the dummy stub has the same size as complete PMODE/W or D3X extender, but hey, feel free to use it nevertheless

> Is that before or after UPXing?

Some people do refuse UPX

> You mean GNU as? Yeah, I dunno why anybody bothers using that as a
> stand-alone assembler in lieu of YASM, NASM, FASM, etc.

Why do you think GAS is better ?

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

> It's sad that DLLs are so scarcely used in DOS. That's why complex programs
> are so fat because the libraries are staticaly linked.

MPLAYER is fat because of all the stupid proprietary codecs (and PTHREAD ?) Blame people inventing/promoting those, not D maintainers for lack of DLL support

> What would be if e. g. allegro.dll is loaded by all programs which use
> allegro instead of having a copy of allegro in each of them?

Allegro was always buggy for me

I don't like DLL hell ... the argument with sharing some code sounds good, but finally isn't: D maintainers outsourced CWSDPMI, saving just 20 KiB, but even then a "Hello world" has 50 ... 100 KiB left ... and with "serious" applications, this argument will decay even more

And, the compatibility (exchange a DLL against a newer one, and nothing will break), is a nice dream ... but not the reality

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

> TDE, VIM, FED, FTE, VILE, GZIP, BZIP2, DOSFSCK, FreeBASIC, FreePascal,
> Ghostscript, Quake, LAME, NASM, NDISASM, JASSPA MicroEmacs, SBC, MAME,
> Doom Legacy, Ardi's Executor, YASM, UPX, XPDF, Dungeon Crawl, ADOM,
> NetHack, Perl, Python, Ruby, Unrar, p7zip, Info-ZIP's ZIP + UNZIP,
> LHA/Unix, LZOP, AdvanceComp, bash, GNU find, GNU tar, GNU sed, GNU awk,
> GNU grep, BIEW, DJTAR, etc. etc. etc.

Just to list some DGPJJ generated progs is NO scientific prove! But at least you avoided to add GDB to you list.

---
MS-DOS forever!

It's gone - an error page comes up.

> BTW, that 17k .EXE, is that from 1.8 beta? Does that include DOS extender
> or just the DOS/4GW stub?

It's from 1.7a. And it is a PE binary with HX of course - I usually don't touch the DOS4G stuff - and without DPMI host included (also of course). I bet it can be improved further without tricks, there are still some WLINK weaknesses which bloat the binary.

> Is that before or after UPXing?

Please stop promoting this UPX thing! There were some reasons for packing executables in the far distant past, but these times are gone and won't come back. Nowadays it's just annoying - remember my "NASM benchmark" in the FASM forum!

---
MS-DOS forever!

> And then the program can't use smart-linking to weed out all the unused
> Allegro functions, and the application/run-time is even bigger than it
> would have been if allegro had been statically linked in the first place.

The fact that in case of a primitive OS like DOS sometimes more memory is used at run-time is irrelevant IMO considering the freed disk space. It is bad programming practice to link a library just to use a small part of its code.

Sometimes code can't be statically linked because of conflicting licence issues. And if you don't have the source code of a program and there is a problem on your system with a part of its code, if the code is included in a DLL, you can simply replace it with a more compatible one or write your own if you know the API.

> And you still have to deal with all the version issues.

In most cases if you use the newest version there are no problems. Even if there are such situations, they are marginal in practice. How many times you bumped into this trouble?

> Application-side DLL's are generally a bad thing IMO.

There are PROs and CONs concerning the use of DLLs, but PROs are dominant IMO. If you don't like it, don't use it.

> MPLAYER is fat because of all the stupid proprietary codecs (and PTHREAD
> ?) Blame people inventing/promoting those, not D maintainers for lack
> of DLL support

You don't know what you are talking about. The proprietary codecs are external modules, that's why Michael tried to implement the DLL loader... AFAIK pthreads is not used in the DOS port, there is no adequate pthreads DJGPP port (the one which I know to exist is unusable with Mplayer).

> I don't like DLL hell ... the argument with sharing some code sounds good,
> but finally isn't: D maintainers outsourced CWSDPMI, saving just 20 KiB,
> but even then a "Hello world" has 50 ... 100 KiB left ... and with
> "serious" applications, this argument will decay even more

Try to logically analize your stance.

> It's gone - an error page comes up.

I have downloaded both DOS and WIN versions. If someone needs I can upload it somewhere.

---
DOS gives me freedom to unlimited HW access.

> Please stop promoting this UPX thing! There were some reasons for packing
> executables in the far distant past, but these times are gone and won't
> come back.

Why? There are cases when you need to shrink progs to limited space like a boot diskette or small flashdisk. Even it may helps loading from slow media when fast CPU is available. I don't want to force somebode to UPX everything I can do it myself but think is a good thing :)

---
DOS gives me freedom to unlimited HW access.

> please provide some scientific evidence for your claims! I have some
> doubts, because I'm unable to see how DGPJJ has made *my* life easier.

DJGPP made my "life" easier indeed.

> However, it doesn't matter what DGPJJ has "done" in the past. What's
> relevant is if it is *still* the best choice for a DOS compiler. IMO: No.

Why is this question relevant? Let me just say: "Choose the right tool for the right job."

---
Forum admin

> No, they aren't bloated, but they aren't as small as they could be. I've
> never been able to recompile the LIBC.A (tried yet again yesterday,

Did you ask at comp.os.msdos.djgpp? A nice guy to write with is Juan.

> unsuccessfully), but using -Os would probably help a little. (Most stuff
> seems to be compiled using -O2, which isn't totally optimal for size.)

But sometimes I want to optimize for speed.

> There is no "one size fits all" here.

Not only here.

> You can always disable cmdline globbing, arg parsing, and/or env. file

I always forget about that.

> loading if you want extra space (see CRT0.H). And don't forget UPX. (But
> yes, 2.04 binaries are noticably a tiny bit bigger, symlink support?? I
> dunno ....)

Don't know, but I will no longer develop using djdev203. Hopefully this will force getting final djdev204 out some day.

> If only *nix people weren't so obsessed with using obscure features in the
> ultra-super-modern latest version of MAKE/BASH/etc. which makes ports so
> much harder!

Depends on your experience. In the beginning I hated Make or Bash, but I learned more and more and now I like it (most times). For example I wrote my own Makefile for Dmidecode, because the one supplied was "damn stupid".

---
Forum admin

> But sometimes I want to optimize for speed.

OpenWatcom optimizes by default for a balance between size and speed (good).

For DJGPP, if you really want speed, use -O3 -march=native (or -mtune=generic). For size, use -Os -fomit-frame-pointer -march=i386 (and check CRT0.H for stuff to disable).

> Don't know, but I will no longer develop using djdev203. Hopefully this
> will force getting final djdev204 out some day.

Blame "real life" (tm) for getting in the way.

> Depends on your experience. In the beginning I hated Make or Bash, but I
> learned more and more and now I like it (most times). For example I wrote
> my own Makefile for Dmidecode, because the one supplied was "damn stupid".
>

Well, I could write all my sed scripts in GNU sed, but that's incompatible with (much) older variants: CSED or SEDMOD or HHSED (but which are much smaller, much faster). Usually, I find a way to make it work in all of 'em. (What does bash v3 offer that's so great, anyways? Arrays??)

---
Know your limits.h

> > TDE, VIM, FED, FTE, VILE, GZIP, BZIP2, DOSFSCK, FreeBASIC, FreePascal,
> > Ghostscript, Quake, LAME, NASM, NDISASM, JASSPA MicroEmacs, SBC, MAME,
> > Doom Legacy, Ardi's Executor, YASM, UPX, XPDF, Dungeon Crawl, ADOM,
> > NetHack, Perl, Python, Ruby, Unrar, p7zip, Info-ZIP's ZIP + UNZIP,
> > LHA/Unix, LZOP, AdvanceComp, bash, GNU find, GNU tar, GNU sed, GNU awk,
> > GNU grep, BIEW, DJTAR, etc. etc. etc.
>
> Just to list some DGPJJ generated progs is NO scientific prove! But at
> least you avoided to add GDB to you list.

You mean none of those are useful to you anymore??

---
Know your limits.h

> DJGPP made my "life" easier indeed.

Thanks for telling us!

> Why is this question relevant?

A "why" question is always dangerous. Usually I don't reply to such a question, because I think people should use their brain and analyze things for themselves, but since you're the admin I will make an exception and explain it for you:

First, I - slightly "by the way" - claimed that OW is superior to DGPJJ and supplied 4 arguments as backup:

- OW makes smaller binaries
- debugger is better
- memory model is better
- speed isn't better, but this isn't too important on modern cpus

all 4 arguments are about attributes of OW itself and they can be "verified"/"falsified".

Now, flox decided to stand up and defend DPGJJ by also bringing 4 arguments on the table:

- tools can be easily ported from Loonix
- gcc is under heavy development
- it makes life easier
- without DGPJJ DOS would be dead

This reply changes the topic of this branch of this thread to "OW vs DGPJJ" and therefore your "why" question is invalid.

But to summarize, in my reply to flox, I expressed my doubts about the quality of some of his arguments. IMO it is a rather hybrid set and some aren't acceptable (or, in other words, "irrelevant") when it comes to the question whether current DGPJJ is inferior to current OW or not! IMO arguments 2,3 and 4 are such "irrelevant" ones, because they are just opinions, "historical" and/or no attribute of DGPJJ - in short, they are not scientific.

> Let me just say: "Choose the right tool for the right job."

Thanks for your hint, but this is really off-topic. As already mentioned, this branch of this thread is about "OW vs DGPJJ"! I know, you regard this "question" as irrelevant, but then just ignore this branch.

---
MS-DOS forever!

> You mean none of those are useful to you anymore??

No, I don't mean that. It's just off-topic. See my reply to rr. You and rr really should try to improve your scientific and/or rhetoric skills.

---
MS-DOS forever!

> Why? There are cases when you need to shrink progs to limited space like a
> boot diskette or small flashdisk. Even it may helps loading from slow media
> when fast CPU is available. I don't want to force somebode to UPX
> everything I can do it myself but think is a good thing :)

Yes. But it has its catches and it is very often used unnecessarily IMO. Therefore there's no need to promote it.

---
MS-DOS forever!

> Yes. But it has its catches and it is very often used unnecessarily IMO.

What 'catches' do you mean? Except taking aditional time for decompress I don't know. Also UPX may corrupt some binaries (e.g. if you run UPX *.* in your windows\system dir then you will probably not boot anymore :) but it didn't happened for DJGPP bins never for me and I always test the binary after packing if it still works.

---
DOS gives me freedom to unlimited HW access.

> 'em. (What does bash v3 offer that's so great, anyways? Arrays??)

I have no idea. I still use pre-compiled Bash version 2.05b.0(1).

---
Forum admin

> > DJGPP made my "life" easier indeed.
>
> Thanks for telling us!

No problem. You told us before that DJGPP didn't make your life easier. So 1:1, which leads to...

> > Why is this question relevant?
>
> A "why" question is always dangerous.

For the questioner or the replier?

> Usually I don't reply to such a

So you are an ignoramus?

> question, because I think people should use their brain and analyze things
> for themselves,

I did and my answer was "Choose the right tool for the right job."

> but since you're the admin I will make an exception and
> explain it for you:

No need to dispense charity.

> - OW makes smaller binaries
> - debugger is better
> - memory model is better
> - speed isn't better, but this isn't too important on modern cpus
>
> all 4 arguments are about attributes of OW itself and they can be
> "verified"/"falsified".

OK, but please understand that arguments 2 and 3 might not be relevant for all tasks/people.

---
Forum admin

> > Yes. But it has its catches and it is very often used unnecessarily IMO.
>
> What 'catches' do you mean? Except taking aditional time for decompress I
> don't know.

catches:

- additional time for decompressing.
- wont work if the program needs to read additional info from the binary.
- destroys the delayed, page-oriented "demand loading" of a binary in Win32

generally, it adds a layer of "insecurity" (I think it was sol who once dared to mention that). Of course you can test the binary after packing, but you might make a mistake and it happens to work just for you.

---
MS-DOS forever!

> > A "why" question is always dangerous.
>
> For the questioner or the replier?

Usually for the replier because it often turns out to be a trap. But also for the questioner because it gives the replier the opportunity to write novels.

> I did and my answer was "Choose the right tool for the right job."

Then you should improve your logical skills, since this answer is "desperately" off-topic.

> OK, but please understand that arguments 2 and 3 might not be relevant for
> all tasks/people.

It's pretty irrelevant how relevant this issue is for other people . I bet that 99.9999999% of the people on this planet (and roughly 99.9999999999999999999999999999999999999999999999999999999999999% of all beings in this universe) don't care at all which one of those 2 tools is "better". But that doesn't mean that we cannot discuss these things here.

---
MS-DOS forever!

> > I did and my answer was "Choose the right tool for the right job."
>
> Then you should improve your logical skills, since this answer is
> "desperately" off-topic.

It's very funny to hear that from you, because this topic (thread) is about LadSoft/CC386. So this "DJGPP vs. OW" stuff is off-topic too. But feel free to start a new thread in "Developers" or "Miscellaneous".

---
Forum admin

> It's pretty irrelevant how relevant this issue is for other people . I
> bet that 99.9999999% of the people on this planet

99.9999999% is probably a safe bet, given that most prople, including application users, don't know or care about programmers' peoblems.

> (and roughly
> 99.9999999999999999999999999999999999999999999999999999999999999% of all
> beings in this universe) don't care at all which one of those 2 tools is
> "better".

But this is different. Do you know who is out there?

Online at SAC sites, in /utilprog:
ccdl374e.zip - DOS and MC68K compilers & tools
cwdl374e.zip - Windows compiler, graphical IDE & tools

SAC site lists:
UK - http://uk.geocities.com/short_stop_uk/lists/sac.htm
US - http://short.stop.home.att.net/lists/sac.htm

Other files:

http://third.base.home.att.net/dl/cxdl374e.zip - CC386 - Most DOS & Windows compiler & other files, in dir tree for manual installation

http://third.base.home.att.net/dl/cwdl374s.zip - CC386 - Source code for compilers, NASM, VALX & other tools

http://third.base.home.att.net/dl/cwdl374l.zip - CC386 - Source code for runtime libraries for DOS/Windows/MC68K

http://third.base.home.att.net/dl/valx.zip - Linker

http://third.base.home.att.net/dl/mksym.zip - Make symbol tables

ftp://ftp.uni-koeln.de/pc/msdos/programming/grdbdl94.zip - Debugger

OK, then there is no longer a need to mirror those files here.

---
Forum admin

> > (and roughly
> > 99.9999999999999999999999999999999999999999999999999999999999999% of
> all
> > beings in this universe) don't care at all which one of those 2 tools
> is
> > "better".
>
> But this is different. Do you know who is out there?

It's a mathematically exact calculation of an expectancy value based on scientific knowledge of 2008 AD.

---
MS-DOS forever!

> It's very funny to hear that from you, because this topic (thread) is
> about LadSoft/CC386. So this "DJGPP vs. OW" stuff is off-topic too. But
> feel free to start a new thread in "Developers" or "Miscellaneous".

Yes, "OW vs. DGPJJ" is off-topic, but this happens every now and then within a thread. But your answer was "desperately" off-topic, that is, you answered a question which has not been asked at all, and that is much worse.

(I admit it, I can be very annoying )

---
MS-DOS forever!

> > It's very funny to hear that from you, because this topic (thread) is
> > about LadSoft/CC386. So this "DJGPP vs. OW" stuff is off-topic too. But
> > feel free to start a new thread in "Developers" or "Miscellaneous".
>
> Yes, "OW vs. DGPJJ" is off-topic, but this happens every now and then

I see. I return to TP6 (best TP ever!) now.

---
Forum admin