Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Steve

Homepage E-mail

US,
25.02.2008, 20:01
 

Ladsoft / CC386 back online (Announce)

Post reply

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

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

Homepage

Germany (South),
27.02.2008, 08:29

@ Steve
 

Ladsoft / CC386 back online

Post reply

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!
rr

Homepage E-mail

Berlin, Germany,
27.02.2008, 09:48

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> 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
Japheth

Homepage

Germany (South),
27.02.2008, 18:30

@ rr
 

Ladsoft / CC386 back online

Post reply

> Rely on "DOS386" and you are lost. ;-)

Yes, DOS386 is talking a lot. :-D 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!
DOS386

01.03.2008, 02:37

@ rr
 

Ladsoft / CC386 back online

Post reply

> Rely on "DOS386" and you are lost.
Either I'm failing to see the point of this post or there is none :-P

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 :lol:

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 :hungry:

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

Homepage

Usono,
27.02.2008, 19:14

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> 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.
Japheth

Homepage

Germany (South),
29.02.2008, 09:02
(edited by Japheth, 29.02.2008, 09:22)

@ Rugxulo
 

Ladsoft / CC386 back online

Post reply

> 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. :-D (Still better than ASS of course)

---
MS-DOS forever!
rr

Homepage E-mail

Berlin, Germany,
29.02.2008, 10:02

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> 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. :-P

---
Forum admin
Laaca

Homepage

Czech republic,
29.02.2008, 16:46

@ rr
 

Ladsoft / CC386 back online

Post reply

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!
flox

Homepage

29.02.2008, 17:21

@ Laaca
 

Ladsoft / CC386 back online

Post reply

> 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!
Japheth

Homepage

Germany (South),
29.02.2008, 20:55

@ flox
 

Ladsoft / CC386 back online

Post reply

> 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!
RayeR

Homepage

CZ,
29.02.2008, 21:36

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> 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.
Rugxulo

Homepage

Usono,
01.03.2008, 00:42

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> > 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? :-D
Japheth

Homepage

Germany (South),
01.03.2008, 05:24

@ Rugxulo
 

Ladsoft / CC386 back online

Post reply

> 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. :-D

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
02.03.2008, 00:34

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> > 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. :-D
You mean none of those are useful to you anymore?? :surprised: :crying:

---
Know your limits.h
Japheth

Homepage

Germany (South),
02.03.2008, 08:41

@ Rugxulo
 

Ladsoft / CC386 back online

Post reply

> You mean none of those are useful to you anymore?? :surprised: :crying:
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!
rr

Homepage E-mail

Berlin, Germany,
01.03.2008, 20:09

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> 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
Japheth

Homepage

Germany (South),
02.03.2008, 08:34
(edited by Japheth, 02.03.2008, 08:53)

@ rr
 

Ladsoft / CC386 back online

Post reply

> 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!
rr

Homepage E-mail

Berlin, Germany,
02.03.2008, 14:48

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> > 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
Japheth

Homepage

Germany (South),
02.03.2008, 16:10

@ rr
 

Ladsoft / CC386 back online

Post reply

> > 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" :-D 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 :-D . 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!
rr

Homepage E-mail

Berlin, Germany,
02.03.2008, 18:03

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> > 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" :-D 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
Japheth

Homepage

Germany (South),
03.03.2008, 11:44

@ rr
 

Ladsoft / CC386 back online

Post reply

> 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 :-D )

---
MS-DOS forever!
rr

Homepage E-mail

Berlin, Germany,
03.03.2008, 13:25

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> > 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. :-P

---
Forum admin
Rugxulo

Homepage

Usono,
04.03.2008, 18:10

@ Japheth
 

annoying? moi?

Post reply

Just to continue the off-topic theme ... :-D

> (I admit it, I can be very annoying :-D )
You too? I constantly annoy my family, mostly with my jokes (seems they don't have a decent sense of humor, heh). Even you didn't seem to get my _Red Dwarf_ reference in the other thread (roast beef). Oh well. (As previously mentioned, my given name is Anthony, and as I often remind myself, you can't spell "ANthONY" without "ANNOY".) :rotfl:

http://www.wordinfo.info/words/index/info/view_unit/4045/1/?spage=2&letter=O

> annoy (uh NOI)
> 1. To cause uneasiness to; especially, by repeated acts; make
> somewhat angry.
> 2. To trouble; to vex: "I was annoyed by the disturbance of my
> afternoon nap."
>
> "Please, do not annoy me with your interruptions while I am trying
> to explain this recipe."
> 3. Etymology: from Anglo-French anuier, from Old French enuier, "to weary, > to vex"; from Late Latin inodiare, "to make loathsome"; from Latin,
> (esse) in odio, "(it is to me) hateful"; ablative, or a grammatical
> form, of odium, "hatred".

---
Know your limits.h
Steve

Homepage E-mail

US,
03.03.2008, 02:55

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> It's pretty irrelevant how relevant this issue is for other people :-D . 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? :lol3:
Japheth

Homepage

Germany (South),
03.03.2008, 11:31

@ Steve
 

Ladsoft / CC386 back online

Post reply

> > (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? :lol3:
It's a mathematically exact calculation of an expectancy value based on scientific knowledge of 2008 AD.

---
MS-DOS forever!
flox

Homepage

03.03.2008, 17:19

@ Japheth
 

Ladsoft / CC386 back online

Post reply

I never said, that it is scientific and yes - it is my opinion and was only brainstorming :-)

> - tools can be easily ported from Loonix
> - gcc is under heavy development
> - it makes life easier
> - without DGPJJ DOS would be dead
> 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.
rr

Homepage E-mail

Berlin, Germany,
29.02.2008, 17:25

@ Laaca
 

Ladsoft / CC386 back online

Post reply

> 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
flox

Homepage

29.02.2008, 18:13

@ rr
 

Ladsoft / CC386 back online

Post reply

> > 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.
Khusraw

29.02.2008, 18:46

@ rr
 

Ladsoft / CC386 back online

Post reply

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?
RayeR

Homepage

CZ,
29.02.2008, 21:28

@ Khusraw
 

Ladsoft / CC386 back online

Post reply

> 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.
Khusraw

29.02.2008, 22:07

@ RayeR
 

Ladsoft / CC386 back online

Post reply

> 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.
RayeR

Homepage

CZ,
29.02.2008, 23:48

@ Khusraw
 

Ladsoft / CC386 back online

Post reply

> 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.
Rugxulo

Homepage

Usono,
01.03.2008, 00:44

@ Khusraw
 

Ladsoft / CC386 back online

Post reply

> 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!)
jaybur

Homepage E-mail

UK,
29.02.2008, 22:44

@ RayeR
 

Ladsoft / CC386 back online

Post reply

> 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.
Khusraw

01.03.2008, 13:51

@ jaybur
 

Ladsoft / CC386 back online

Post reply

> 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.
DOS386

01.03.2008, 02:54

@ Khusraw
 

D | DLL hell | MPLAYER

Post reply

> 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 :-P

> 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 ***
Khusraw

01.03.2008, 14:02

@ DOS386
 

D | DLL hell | MPLAYER

Post reply

> 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 :-P
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.
Rugxulo

Homepage

Usono,
01.03.2008, 00:30

@ rr
 

Ladsoft / CC386 back online

Post reply

> 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. :-P
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! :-|
rr

Homepage E-mail

Berlin, Germany,
01.03.2008, 20:25

@ Rugxulo
 

Ladsoft / CC386 back online

Post reply

> 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. :-D

> 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
Rugxulo

Homepage

Usono,
02.03.2008, 00:32

@ rr
 

Ladsoft / CC386 back online

Post reply

> 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
rr

Homepage E-mail

Berlin, Germany,
02.03.2008, 14:15

@ Rugxulo
 

Ladsoft / CC386 back online

Post reply

> '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
Rugxulo

Homepage

Usono,
01.03.2008, 00:26

@ Japheth
 

DJGPP and OpenWatcom

Post reply

> 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. :-D (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??)
DOS386

01.03.2008, 02:45

@ Rugxulo
 

DJGPP and OpenWatcom

Post reply

> > 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) :clap:

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 :hungry:

> Is that before or after UPXing?
Some people do refuse UPX :lol3:

> 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 ? :hungry:

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

Homepage

Germany (South),
01.03.2008, 07:01

@ Rugxulo
 

DJGPP and OpenWatcom

Post reply

> 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!
RayeR

Homepage

CZ,
01.03.2008, 14:46

@ Japheth
 

DJGPP and OpenWatcom

Post reply

> 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.
Japheth

Homepage

Germany (South),
02.03.2008, 09:31

@ RayeR
 

DJGPP and OpenWatcom

Post reply

> 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!
RayeR

Homepage

CZ,
02.03.2008, 13:43

@ Japheth
 

DJGPP and OpenWatcom

Post reply

> 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.
Japheth

Homepage

Germany (South),
02.03.2008, 15:59

@ RayeR
 

DJGPP and OpenWatcom

Post reply

> > 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!
RayeR

Homepage

CZ,
03.03.2008, 19:01

@ Japheth
 

DJGPP and OpenWatcom

Post reply

> - destroys the delayed, page-oriented "demand loading" of a binary in
> Win32
I don't know what's this but I can confirm that ~1% win32 files I had compressed by UPX then didn't work. I don't remember that case when it works after packing but failed later/on other PC.

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

Homepage

Germany (South),
04.03.2008, 09:00

@ RayeR
 

DJGPP and OpenWatcom

Post reply

> I don't know what's this but I can confirm that ~1% win32 files I had
> compressed by UPX then didn't work.
Windows (some versions only?) loads those parts of the binary only which are "used". OTOH an exe-packer will have to read large parts (or all) of the binary first to unpack it. So both the time to start the binary and the "working set" most likely are worse with a packed binary.

---
MS-DOS forever!
Rugxulo

Homepage

Usono,
04.03.2008, 15:06

@ Japheth
 

DJGPP and OpenWatcom

Post reply

> > I don't know what's this but I can confirm that ~1% win32 files I had
> > compressed by UPX then didn't work.
>
> Windows (some versions only?) loads those parts of the binary only which
> are "used". OTOH an exe-packer will have to read large parts (or all) of
> the binary first to unpack it. So both the time to start the binary and
> the "working set" most likely are worse with a packed binary.
It's mentioned in the docs. In other words, don't compress something you use a bunch of instances of at the same time (make, bash, your favorite text editor perhaps?). It wastes memory in that case. Otherwise, it shouldn't be an issue.

If the compressed item doesn't work any more, it's either using some "dirty hacks" or a genuine bug in UPX (i.e. report it on SourceForge). Always keep a backup of system files if you want to compress 'em.
Rugxulo

Homepage

Usono,
04.03.2008, 15:15

@ Japheth
 

Ladsoft / CC386 back online

Post reply

> (CC386 is not that important IMO since OW's WCC386 is better)
Well, OpenWatcom doesn't have a DOS installer. But you're correct, both support some of the same extenders. However, (and I've never messed with this aspect much), does OpenWatcom support C99? AFAIK, no, not officially, only very partially through (undocumented) -za99 whereas CC386 openly claims to support almost all of C99 (untested by me, just reporting what I heard). Anyways, CC386 outputs to .ASM, which goes to its hacked version of NASM. OpenWatcom outputs straight to .OBJ, so it needs WDIS to convert it to .ASM. But yes, CC386 isn't optimizing, and OpenWatcom is.

---
Know your limits.h
Matjaz

Homepage E-mail

Maribor, Slovenia,
04.03.2008, 16:49

@ Rugxulo
 

Ladsoft / CC386 back online

Post reply

> Well, OpenWatcom doesn't have a DOS installer.
Actually it does have a DOS installer. But you need to compile it yourself. However, it doesn't work as a SFX (as windows installer does), you neded to manualy extract windows installer and put dos installer into the root dir of installation. It would be good for a CD distribution.
Rugxulo

Homepage

Usono,
04.03.2008, 18:05

@ Matjaz
 

Ladsoft / CC386 back online

Post reply

> > Well, OpenWatcom doesn't have a DOS installer.
>
> Actually it does have a DOS installer. But you need to compile it
> yourself. However, it doesn't work as a SFX (as windows installer does),
> you neded to manualy extract windows installer and put dos installer into
> the root dir of installation. It would be good for a CD distribution.
Officially, I mean, they don't have one (yet). They used to (six months ago?) have a compiled (beta) version on their FTP site, but I don't think it's there anymore. And that one was compiled by zlib + libzip, so it didn't need you to unpack the Win32 .ZIP sfx. I tried it, it worked. Dunno what their plans for it are.
Steve

Homepage E-mail

US,
01.03.2008, 06:28

@ Steve
 

Ladsoft / CC386 dead again

Post reply

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

Homepage

CZ,
01.03.2008, 14:43

@ Steve
 

Ladsoft / CC386 dead again

Post reply

> 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.
Steve

Homepage E-mail

US,
03.03.2008, 04:55

@ Steve
 

Alternate Ladsoft file locations

Post reply

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
rr

Homepage E-mail

Berlin, Germany,
03.03.2008, 09:44

@ Steve
 

Alternate Ladsoft file locations

Post reply

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

---
Forum admin
Steve

Homepage E-mail

US,
04.03.2008, 09:49

@ Steve
 

Alternate Ladsoft file locations - Revised

Post reply

CC386 at SAC sites, in /utilprog - see lists, UK or US
ccdl374e.zip - DOS and MC68K compilers & tools
cwdl374e.zip - Windows compiler, graphical IDE & tools

CC386 at most FreeDOS sites, in /files/devel/c/cc386/374/ - see lists, UK or US
cdl374e.zip - DOS and MC68K compilers & tools
cwdl374e.zip - Windows compiler, graphical IDE & tools
cwdl374s.zip - Source code for compilers, NASM, VALX & other tools
cwdl374l.zip - Source code for runtime libraries for DOS/Windows/MC68K

The same files are also at Rugxulo's RUFFIDEA

These 4 files:
cwdl374e.zip
cwdl374l.zip
cwdl374s.zip
grdbdl94.zip - Debugger

are in:

ftp://ftp.uni-koeln.de/pc/msdos/programming/
http://ftp.uni-koeln.de/pc/msdos/programming/

ftp://ftp.rrz.uni-koeln.de/pc/msdos/programming/
http://ftp.rrz.uni-koeln.de/pc/msdos/programming/

ftp://gd.tuwien.ac.at/pc/dos/msdos/programming/
http://gd.tuwien.ac.at/pc/dos/msdos/programming/
rsync://gd.tuwien.ac.at/pc/dos/msdos/programming/

ftp://gd4.tuwien.ac.at/pc/dos/msdos/programming/
http://gd4.tuwien.ac.at/pc/dos/msdos/programming/
rsync://gd4.tuwien.ac.at/pc/dos/msdos/programming/

ftp://ftp.at.gnucash.org/pc/dos/msdos/programming/
http://at.gnucash.org/pc/dos/msdos/programming/
rsync://at.gnucash.org/pc/dos/msdos/programming/

ftp://ftp.uni-hannover.de/pub/mirror/msdos/programming/

ftp://ftp.rrzn.uni-hannover.de/pub/msdos/programming/


Last group:
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/valx.zip - Linker

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

rr: Maybe it would be a good idea to have second locations for these 3 files.
Steve

Homepage E-mail

US,
04.03.2008, 14:24

@ Steve
 

Alternate Ladsoft file locations - Slightly revised

Post reply

> ccdl374e.zip - DOS and MC68K compilers & tools
MC68K cross-compiler/assembler/etc. are no longer in this package, but in their own:
http://third.base.home.att.net/dl/t68k366e.zip


Source code packages still have everything.
DOS386

04.03.2008, 01:57

@ Steve
 

Ladsoft / CC386 back online

Post reply

> http://members.tripod.com/~ladsoft/
>
> All CC386 3.74 files are up. Some other files too, but not the whole of
> the former site.
Dead ...

But:

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

EOD

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

Homepage E-mail

US,
04.03.2008, 05:25

@ DOS386
 

Ladsoft / CC386 back online

Post reply

> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/c/cc386/374/
Missing:
cxdl374e.zip - Most DOS & Windows compiler & other files, in dir tree for manual installation. Also the other tools I listed.

> EOD
Not your decision.
Back to index page
Thread view  Board view
22632 Postings in 2109 Threads, 402 registered users, 395 users online (0 registered, 395 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum