BP 7.0 has seconds of delay under WinXP
Ruud
I have a weird problem: when working with BP 7.0 in a DOS box in
Windows XP on my laptop (Dell Latitude D510), I sometimes have to wait
seconds before what ever I type appears on my screen. This includes
cursor movements. I don't experience any od these problems on any of
other (slower) computers/laptops. Any idea?
Many thanks for any info, suggestion or help!
Groetjes, Ruud Baltissen
Marco van de Voort
Try to backup and then kill the PIF file.
Ruud
> Try to backup and then kill the PIF file.
You mean the PIF files as used with Win 3.11 ??? None found. I'm using
a minimum system anyway; leave anything away and TP won't start up at
all.
So because of these delay problems, I decided to try FPC again after a
long time (two years?). I used it before but I two problems with it:
- too bulky EXE-files; for example 200 KB vs. 30 KB for one of my
programs
- the IDE interface wasn't stable IMHO
I downloaded 2.2.4 and it works like a charm. It seems that for the
most of my projects it is "Good bye, TP!". But tinkering around with
8088 machines means that TP, even version 3.0, still is needed from
time to time.
Groetjes, Ruud Baltissen
Marco van de Voort
>> Try to backup and then kill the PIF file.
>
> You mean the PIF files as used with Win 3.11 ??? None found. I'm using
> a minimum system anyway; leave anything away and TP won't start up at
> all.
Afaik win95+ also use them to store properties of programs.
> So because of these delay problems, I decided to try FPC again after a
> long time (two years?). I used it before but I two problems with it:
> - too bulky EXE-files; for example 200 KB vs. 30 KB for one of my
> programs
Won't ever change. 32-bit code is simply bulkier, and the RTL is portable,
not handwritten 16-bit assembler.
Do you still use floppies daily?
> - the IDE interface wasn't stable IMHO I downloaded 2.2.4 and it works
> like a charm. It seems that for the most of my projects it is "Good bye,
> TP!". But tinkering around with 8088 machines means that TP, even version
> 3.0, still is needed from time to time.
In 2.2.4 via 2.2.2 the IDE is roughly on the same level as in the 1.0.x
series.
2.4.0 (real soon now) will hopefully further improve the help (an optional
chm download that is quicker to decompress and smaller on disk), and I hope
that 2.4.2 in summer/next fall will improve the debugger support. (moving to
gdb7)
Robert Riebisch
> I have a weird problem: when working with BP 7.0 in a DOS box in
> Windows XP on my laptop (Dell Latitude D510), I sometimes have to wait
> seconds before what ever I type appears on my screen. This includes
> cursor movements. I don't experience any od these problems on any of
> other (slower) computers/laptops. Any idea?
Are you talking about the BP IDE?
--
Robert Riebisch
Bitte NUR in der Newsgroup antworten!
Please reply to the Newsgroup ONLY!
hartnegg
> when working with BP 7.0 in a DOS box in
> Windows XP on my laptop (Dell Latitude D510), I sometimes have to wait
> seconds before what ever I type appears on my screen. This includes
> cursor movements.
Try in cmd.exe instead of command.com
Reactions to keyboard input are much quicker there.
Also try loading dosidle in that dos window.
regards,
Klaus
Rugxulo
On Dec 30, 5:15 am, Marco van de Voort <mar...@stack.nl> wrote:
> On 2009-12-30, Ruud <Ruud.Baltis...@apg.nl> wrote:
>
> > So because of these delay problems, I decided to try FPC again after a
> > long time (two years?). I used it before but I two problems with it:
> > - too bulky EXE-files; for example 200 KB vs. 30 KB for one of my
> > programs
>
> Won't ever change. 32-bit code is simply bulkier, and the RTL is portable,
> not handwritten 16-bit assembler.
8086 instructions are max. 6 bytes each. 386 are max. 15 bytes each. I
don't really know of any compiler that really really prefers small
size over speed (definitely not GCC, even with -Os). If you want small
size, you probably have to use assembly. BTW, I'll be honest, I don't
know how much of FPC relies on DJGPP, but the latter is heavily about
POSIX, LFNs, compatibility, etc. TP7 has none of that. If you don't
need it, don't use it.
P.S. http://upx.sf.net :-))
> Do you still use floppies daily?
Yes, definitely. Oh, you meant him? ^_^
> > But tinkering around with 8088 machines means that TP, even version
> > 3.0, still is needed from time to time.
Does TP3 really have any advantage over 5.5?? Maybe faster compiles??
BTW, you are officially a hardcore retro dude if you still use
8086/8088. Search for Jim Leonard's or Mike Chamber's software. :-)
Marco van de Voort
> know how much of FPC relies on DJGPP,
Extender (go32.exe) and linker. (ld.exe). Some additional tools (like
make) are needed to build FPC, but not to use it.
> but the latter is heavily about POSIX, LFNs, compatibility, etc. TP7 has
> none of that. If you don't need it, don't use it.
No POSIX on non Unix platforms. LFN, Delphi compat surely.
> P.S. http://upx.sf.net :-))
Small binaries are not an objective of mine.
>> Do you still use floppies daily?
>
> Yes, definitely. Oh, you meant him? ^_^
I killed off XP last november, so I'm finally floppy-free. (Vista+ don't
need floppies, XP and earlier do for some tasks)
>> > But tinkering around with 8088 machines means that TP, even version
>> > 3.0, still is needed from time to time.
>
> Does TP3 really have any advantage over 5.5?? Maybe faster compiles??
If you care about code and RTL size? Sure I think. It has the smaller COM
memory models that afaik later TPs don't have?
In that the question similar to "Does TP 5.5 really have any
advantage over FPC?" :-)
Rugxulo
On Jan 1, 4:41 am, Marco van de Voort <mar...@stack.nl> wrote:
> On 2009-12-31, Rugxulo <rugx...@gmail.com> wrote:
>
> > know how much of FPC relies on DJGPP,
>
> Extender (go32.exe) and linker. (ld.exe). Some additional tools (like
> make) are needed to build FPC, but not to use it.
So it won't run without go32.exe?? I'm honestly not sure whether that
app does anything at all in DJGPP v2. Well, at least, you don't need
it at all unless you want to co-mingle v1 and v2 apps (and then you'd
still need the old go32). It even calls CWSDPMI, so it's not even a
replacement for that! But it does report memory stats for you (not
useful under some OSes, though, heh).
Long story short: I need to install FPC to test it a bit. :-)
> > but the latter is heavily about POSIX, LFNs, compatibility, etc. TP7 has
> > none of that. If you don't need it, don't use it.
>
> No POSIX on non Unix platforms. LFN, Delphi compat surely.
With DJGPP it's different, they needed to be able to support GNU
tools.
> > P.S.http://upx.sf.net :-))
>
> Small binaries are not an objective of mine.
I know. Let me find the link ...
http://wiki.freepascal.org/Size_Matters
BTW, UPX'd stuff has no penalty in DOS. But for some reason under
Windows UPX'd stuff (e.g. DJGPP apps) run much slower than would be
expected (dirty pages??). So yeah, not recommended there if you care
about speed.
> I killed off XP last november, so I'm finally floppy-free. (Vista+ don't
> need floppies, XP and earlier do for some tasks)
USB floppy drive ftw!! (on Vista too)
> > Does TP3 really have any advantage over 5.5?? Maybe faster compiles??
>
> If you care about code and RTL size? Sure I think. It has the smaller COM
> memory models that afaik later TPs don't have?
I worry if it's buggier due to being older. And I don't think anybody
in particular prefers .COMs over .EXEs since there is no inherent
advantage.
> In that the question similar to "Does TP 5.5 really have any
> advantage over FPC?" :-)
Doubtful. Even I don't have any 286s around here (yet?? heh). So
unless you absolutely enjoy 16-bit programming or know somebody who
needs such compatibility, I wouldn't bother. Then again, is FPC fairly
fast to compile stuff? I would assume it would matter more for old (<
586) machines. How big is the default install? (I really need to test
install it, heh.) Only for such cases (or by chance if something
didn't compile with FPC) would TP55 still be a good thing. Well, and
it fits compressed on a floppy too, IIRC. ;-)
Marco van de Voort
>> > know how much of FPC relies on DJGPP,
>>
>> Extender (go32.exe) and linker. (ld.exe). Some additional tools (like
>> make) are needed to build FPC, but not to use it.
>
> So it won't run without go32.exe??
Afaik no, but I haven't tested that in a decade. If I used dos I simply used
the install with a bunch of files in it. IIRC CWSDPMI is only required if
you have no DPMI provider.
> Long story short: I need to install FPC to test it a bit. :-)
Well, take the fresh dos release of today :-)
>> No POSIX on non Unix platforms. LFN, Delphi compat surely.
>
> With DJGPP it's different, they needed to be able to support GNU
> tools.
Yes, they are not wholly portable, only on top of a POSIX subsystem.
> BTW, UPX'd stuff has no penalty in DOS.
I assume under DOS it is a CPU vs disk-I/O tradeoff. But indeed UPX
frustrating the mapping of binaries that normal OSes have doesn't apply to
dos.
>> I killed off XP last november, so I'm finally floppy-free. (Vista+ don't
>> need floppies, XP and earlier do for some tasks)
>
> USB floppy drive ftw!! (on Vista too)
In recent years I only used floppies for bios updates or loading drivers
during setup of OS installs.
Since Vista, the NT side of things finally also can postload drivers from
mass storage devices.
>> If you care about code and RTL size? Sure I think. It has the smaller COM
>> memory models that afaik later TPs don't have?
>
> I worry if it's buggier due to being older. And I don't think anybody
> in particular prefers .COMs over .EXEs since there is no inherent
> advantage.
They execute faster, and are tighter? Do you need any more reasons? :-)
>> In that the question similar to "Does TP 5.5 really have any
>> advantage over FPC?" :-)
>
> Doubtful. Even I don't have any 286s around here (yet?? heh).
I don't even have anything x86 under a XP2000+ anymore. Actually those two
XP2000+'s are the only pure x86 systems that I have, all the others are
32/64-bit.
I do have slow machines (resp 110 and 40 MHz), but they are non-x86.
> Then again, is FPC fairly
> fast to compile stuff?
Compared to what? TP ? No. GCC? Yes.
> I would assume it would matter more for old (< 586)
> machines. How big is the default install? (I really need to test install
> it, heh.)
Close to 100 MB or so, but the default is full. There are ways to slim them
down (for dos there are individual packages). 10-25MB is probably possible,
and would be roughly equivalent to TP + cmdline Delphi.4
> Only for such cases (or by chance if something didn't compile with FPC)
> would TP55 still be a good thing. Well, and it fits compressed on a floppy
> too, IIRC. ;-)
I'm a BP7 licensee, so even then I would not use TP55. But except for the
Turbo Vision helpfile and manual, I haven't used it since 2003, and before
only for minor testing.
But I had already migrated all my sources from BP to Topspeed Modula2 (on
Dos) before I even started with FPC. So I don't reallly have BP legacy code
anymore.
The only interesting part for playing is Turbo Vision (I have a soft spot
not so much for Dos, but for fullscreen TUI programming), and I have that in
FPC for 98%.
Rugxulo
On Jan 1, 9:49 am, Marco van de Voort <mar...@stack.nl> wrote:
> On 2010-01-01, Rugxulo <rugx...@gmail.com> wrote:
>
> > So it won't run without go32.exe??
>
> Afaik no, but I haven't tested that in a decade. If I used dos I simply used
> the install with a bunch of files in it.
As mentioned, even GO32-V2.EXE needs CWSDPMI, so it's not a substitute
(although old old v1's GO32 predated CWSDPMI and hence didn't need
it). In v2 DPMI is always required unlike v1 where it could optionally
use other stuff (XMS, VCPI). Mixing v1 and v2 apps is rare since most
got updated or are redundant. (FYI, the Desqview/X toolkit used DJGPP
v1.)
> IIRC CWSDPMI is only required if you have no DPMI provider.
Well, the only DOS I know that includes a DPMI provider by default is
Novell DOS / DR-DOS 7 (e.g. my DR-DOS 7.03, which was last updated ten
years ago, woot). And that didn't support virtual memory. I don't know
exactly, but I think it fixed a lot of bugs and became a 32-bit DPMI
host in 7.02 or 7.03 or such, hence multitasking now finally works
with DJGPP apps (although limited to 64 MB a task, max). But that
requires their quirky DR EMM386 to always be loaded. I think the DJGPP
FAQ says that in OpenDOS 7.01 etc. (which wasn't that open, BTW) you
allegedly had to disable the buggy built-in DPMI and let DJGPP apps
use CWSDPMI instead.
QEMM386 might've come with QDPMI (which did somewhat support virtual
memory), but I think that was somewhat buggy too and limited in total
RAM available for use (e.g. I'm told that QEMM 9.01 can only use 256
MB max).
> > Long story short: I need to install FPC to test it a bit. :-)
>
> Well, take the fresh dos release of today :-)
I noticed! :-)
> > BTW, UPX'd stuff has no penalty in DOS.
>
> I assume under DOS it is a CPU vs disk-I/O tradeoff. But indeed UPX
> frustrating the mapping of binaries that normal OSes have doesn't apply to
> dos.
I'm told that DJGPPv2 apps load entirely into memory anyways via the
stub (except for debug info). I guess the DPMI provider could do
something with unused pages, but I don't think most do (even CWSDPMI).
Not sure what DPMIONE does, for instance. UPX is probably more
reliable than DoubleSpace or Stacker, IMHO, but I've never really
tried those (too timid), so I can't say for sure. However, high
cluster size (*shakes fist at 16k for > 512 MB FATs*) is annoying, so
anything to stem the waste ...!
> In recent years I only used floppies for bios updates or loading drivers
> during setup of OS installs.
>
> Since Vista, the NT side of things finally also can postload drivers from
> mass storage devices.
Right, I think that's what XP had to do, use floppies for drivers. And
yes, my P4 / XP updated its BIOS via DOS (I used FreeDOS). But my
Vista laptop has some native Win32 app to do so from within Windows
(weeeeeeiiiirrrrrrdddd!!!).
> >> If you care about code and RTL size? Sure I think. It has the smaller COM
> >> memory models that afaik later TPs don't have?
>
> > I worry if it's buggier due to being older. And I don't think anybody
> > in particular prefers .COMs over .EXEs since there is no inherent
> > advantage.
>
> They execute faster, and are tighter? Do you need any more reasons? :-)
I guarantee that various modern machines vary in their speed of old
code, esp. 16-bit. And it definitely won't run faster than FPC in
DOSEMU x86-64!!! (That reminds me, I never did truly benchmark that
386 DJGPP compile of GCC 2.95.3 on my AMD64 vs. P4 ... I swear it runs
much faster on the AMD.)
> >> In that the question similar to "Does TP 5.5 really have any
> >> advantage over FPC?" :-)
>
> > Doubtful. Even I don't have any 286s around here (yet?? heh).
>
> I don't even have anything x86 under a XP2000+ anymore. Actually those two
> XP2000+'s are the only pure x86 systems that I have, all the others are
> 32/64-bit.
>
> I do have slow machines (resp 110 and 40 MHz), but they are non-x86.
(joking) Don't test me, man, or I'll benchmark compile speeds on my
486. Let's compare TP55 vs. FPC! ;-)
> > Then again, is FPC fairly
> > fast to compile stuff?
>
> Compared to what? TP ? No. GCC? Yes.
GCC, even old versions, is unbearable on a 486. Same with UPX. It's
actually much faster to copy to floppy, go to faster machine, do it
there, drink some coffee, then copy it back. (I'm told Turbo / Borland
C is quite slow on an 8086 also, heh.)
> > How big is the default install?
>
> Close to 100 MB or so, but the default is full. There are ways to slim them
> down (for dos there are individual packages). 10-25MB is probably possible,
> and would be roughly equivalent to TP + cmdline Delphi.4
Eek. Okay, so it's still not nearly as bad as GNU Emacs 23.1
(full). ;-)
I know a lot of people whining about size annoys you, but in my case
it's necessary (and fun / interesting, heh) because of old hardware
and similar limitations (boot floppies). But I'm a rare (weird) case.
> > Only for such cases (or by chance if something didn't compile with FPC)
> I'm a BP7 licensee, so even then I would not use TP55.
Well, 5.5 is the latest freeware version, so that's all most of us
have available.
> The only interesting part for playing is Turbo Vision (I have a soft spot
> not so much for Dos, but for fullscreen TUI programming), and I have that in
> FPC for 98%.
Also used by RHIDE, as you probably know. BTW, that's one major
complaint from DOS / DJGPP users: that XP (and moreso Vista, 7)
crippled or broke RHIDE, which they preferred for its nice interface.
I never really used it, so it's no huge huge loss to me. Still, it was
a useful app. But without a maintainer and without decent OS support,
you're stuck. (If only virtualization and emulation wasn't so slow and
buggy and could share host OS files easily, then we could all be
happy.)
Marco van de Voort
>> > So it won't run without go32.exe??
>>
>> Afaik no, but I haven't tested that in a decade. If I used dos I simply used
>> the install with a bunch of files in it.
>
> As mentioned, even GO32-V2.EXE needs CWSDPMI, so it's not a substitute
> (although old old v1's GO32 predated CWSDPMI and hence didn't need
> it). In v2 DPMI is always required unlike v1 where it could optionally
> use other stuff (XMS, VCPI). Mixing v1 and v2 apps is rare since most
> got updated or are redundant. (FYI, the Desqview/X toolkit used DJGPP
> v1.)
FPC uses v2, apparantly I'm mistaking/outdated since go32.exe is no longer
in SVN
> QEMM386 might've come with QDPMI (which did somewhat support virtual
> memory), but I think that was somewhat buggy too and limited in total
> RAM available for use (e.g. I'm told that QEMM 9.01 can only use 256
> MB max).
When I still used Dos, I used qemm, and had 64MB iirc. No problems with
fpc/go32v2.
>> I assume under DOS it is a CPU vs disk-I/O tradeoff. But indeed UPX
>> frustrating the mapping of binaries that normal OSes have doesn't apply to
>> dos.
>
> I'm told that DJGPPv2 apps load entirely into memory anyways via the
> stub (except for debug info). I guess the DPMI provider could do
> something with unused pages, but I don't think most do (even CWSDPMI).
> Not sure what DPMIONE does, for instance.
Sure, but since they are not memory mapped, they have to be loaded first,
and only then paged out. And that doesn't matter for UPX, if the pages in
mem were compressed before or not.
> UPX is probably more reliable than DoubleSpace or Stacker,
Well, I never had a antivirus balking at stacker. In dos times, I kept the
sources that were for reference only on a small stacker drive.
> IMHO, but I've never really tried those (too timid), so I can't say for
> sure. However, high cluster size (*shakes fist at 16k for > 512 MB FATs*)
> is annoying, so anything to stem the waste ...!
I kept one 1GB partition FAT16, and the rest FAT32 for a long time, till
*nix FAT32 support was mature enough.
>> Since Vista, the NT side of things finally also can postload drivers from
>> mass storage devices.
>
> Right, I think that's what XP had to do, use floppies for drivers. And
> yes, my P4 / XP updated its BIOS via DOS (I used FreeDOS). But my
> Vista laptop has some native Win32 app to do so from within Windows
> (weeeeeeiiiirrrrrrdddd!!!).
There are a lot of different schemes. Even with one manufacterer (we use a
lot of MSI boards at work), it varies with each generation and target
market. Even reactos is slowly moving into this space.
>> They execute faster, and are tighter? Do you need any more reasons? :-)
>
> I guarantee that various modern machines vary in their speed of old
> code, esp. 16-bit. And it definitely won't run faster than FPC in
> DOSEMU x86-64!!! (That reminds me, I never did truly benchmark that
> 386 DJGPP compile of GCC 2.95.3 on my AMD64 vs. P4 ... I swear it runs
> much faster on the AMD.)
On fast computers, I never saw TP code outperform the same code in 32-bit if
the code was non-trivial.
>> I do have slow machines (resp 110 and 40 MHz), but they are non-x86.
>
> (joking) Don't test me, man, or I'll benchmark compile speeds on my
> 486.
You only say that because you know I threw out my 386SX25 last year :-)
>> > Then again, is FPC fairly fast to compile stuff?
>>
>> Compared to what? TP ? No. GCC? Yes.
>
> GCC, even old versions, is unbearable on a 486. Same with UPX. It's
> actually much faster to copy to floppy, go to faster machine, do it
> there, drink some coffee, then copy it back. (I'm told Turbo / Borland
> C is quite slow on an 8086 also, heh.)
I'd guess that FPC speed is roughly GCC minus two specific GCC problems:
- the C disease to reparse headers again and again
- IIRC FPC/go32v2 has AS built in, so no need to call a separate assembler.
However I don't know how big this latter difference is. When FPC got the
internal assembler, the speed up was gigantic, but the "older" FPC model
might not match the GCC model (specially if GCC pipes the assembler to AS),
because afaik FPC wrote it to disk.
> I know a lot of people whining about size annoys you, but in my case
> it's necessary (and fun / interesting, heh) because of old hardware
> and similar limitations (boot floppies). But I'm a rare (weird) case.
I never understood this. Size was always only a side objective, even when I
was on Dos with a 260MB HD. It was always primarily about getting things
done. After the gigabyta era, that pretty much went away, since most of
these factor were in the same magnitude as disk slack, and were no real
factor anymore. (the mp3 collections were bigger problems)
I even assisted people with 4k and 64k demo compos at a certain point, but
these never said it was "necessary", and never posted about their
self-inflicted limitations in newsgroups as if it were a general, universal
rule, something that has always greatly annoyed me in the residual TP
circles.
>> > Only for such cases (or by chance if something didn't compile with FPC)
>> I'm a BP7 licensee, so even then I would not use TP55.
>
> Well, 5.5 is the latest freeware version, so that's all most of us
> have available.
Wasn't it TP7 french?
>> The only interesting part for playing is Turbo Vision (I have a soft spot
>> not so much for Dos, but for fullscreen TUI programming), and I have that in
>> FPC for 98%.
>
> Also used by RHIDE, as you probably know.
Yes, but I never used that one, since IIRC it is a library that is GPL, not
LGPL. There is a BSD equivalent (by sb with an Italian sounding name)
though. The original version released by Borland is afaik not easily found
anymore.
The Pascal version was never released from copyright, so when Borland
started to crack down on 3rd party use of it, FPC switched to a version is a
backport of the freed C++ version to Pascal. This was afaik done by somebody
who wanted to make a graphical clone. (which meant backporting it to FPC
meant revisioning the whole coordinate system again, not trivial)
> BTW, that's one major complaint from DOS / DJGPP users: that XP (and
> moreso Vista, 7) crippled or broke RHIDE, which they preferred for its
> nice interface.
One can also turn it the otherway around and blame RHIDE (or its users) for
never updating it to support windows.
Though afaik currently the dos IDE also works on XP, and even Vista.
> I never really used it, so it's no huge huge loss to me. Still, it was a
> useful app. But without a maintainer and without decent OS support, you're
> stuck. (If only virtualization and emulation wasn't so slow and buggy and
> could share host OS files easily, then we could all be happy.)
I always avoided such dead ends, and moved to the next one that had at least
some life in it, and started working. Or moved on if I didn't care enough to
do that.
Life is to precious to massively invest time to keep tools running
apparantly nobody cares around anymore. Specially when that is time that
isn't invested in the tool.
Rugxulo
On Jan 2, 8:43 am, Marco van de Voort <mar...@stack.nl> wrote:
> On 2010-01-01, Rugxulo <rugx...@gmail.com> wrote:
>
> FPC uses v2, apparantly I'm mistaking/outdated since go32.exe is no longer
> in SVN
From the looks of it, FPC 1.0.10 used to perhaps support v1 also
(source/rtl/go32v1 and source/rtl/go32v2). I think I've read that
DJGPP decided it was too much trouble to support both DPMI and e.g.
VCPI or whatever, so they didn't bother in v2. DPMI was usually the
best way to use lots of RAM on OS/2 and Windows "back in the day."
However, nowadays it's fairly moot as NTVDM isn't regarded as having
much of a future (even on 32-bit).
P.S. I could be wrong, but it seems go32v1 apps run fine on Vista but
not on XP (you can use RSX, though). This is probably the only
improvement I know of, offhand. ;-)
> When I still used Dos, I used qemm, and had 64MB iirc. No problems with
> fpc/go32v2.
But did you use QDPMI or not? I think CWSDPMI is still considered
better.
> Sure, but since they are not memory mapped, they have to be loaded first,
> and only then paged out. And that doesn't matter for UPX, if the pages in
> mem were compressed before or not.
Well, there are other DOS extenders that were demand loaded (e.g.
MOSS, I think), but those were rare. And even that was mostly written
to support a commercial game on 486s, so you kinda had to have
something (as the main .EXE had data combined with it for a 17 MB
whopper).
> > UPX is probably more reliable than DoubleSpace or Stacker,
>
> Well, I never had a antivirus balking at stacker. In dos times, I kept the
> sources that were for reference only on a small stacker drive.
I think various things would have issues, but I never bothered finding
out. The compression ratio is probably subpar anyways (although I
never converted all my .ZIPs to .7z either, so ...). Also not good for
dual booting.
> > IMHO, but I've never really tried those (too timid), so I can't say for
> > sure. However, high cluster size (*shakes fist at 16k for > 512 MB FATs*)
> > is annoying, so anything to stem the waste ...!
>
> I kept one 1GB partition FAT16, and the rest FAT32 for a long time, till
> *nix FAT32 support was mature enough.
MS patents on FAT32 still exist, which is annoying. Last I heard,
Linux moved to a "read-only" hack, then made it where it would only
save the LFN part, not SFN, to avoid problems. Kinda silly in this day
and age, but oh well.
BTW, what I mainly meant was that several DOSes (e.g. official DR-DOS)
never had FAT32 support (and mine never came with any beta TSRs
either), so you're kinda stuck. In short, never ever use FAT16 with >
512 MB. I should've split mine up into several FAT16 partitions so
that it would be 8k clusters instead of 16k (horrible for lots of
small files).
> > I guarantee that various modern machines vary in their speed of old
> > code, esp. 16-bit. And it definitely won't run faster than FPC in
> > DOSEMU x86-64!!!
>
> On fast computers, I never saw TP code outperform the same code in 32-bit if
> the code was non-trivial.
Well, x86-64 has no 16-bit, so DOSEMU has to emulate it. It's
noticeably slow for that, but 32-bit (e.g. DJGPP) is "native speed".
But you're right, even on 486s, 32-bit code is faster because that was
the design intention. So there usually is no comparison. Doesn't mean
there aren't corner cases, but for the most part it does run pretty
fast. DJGPP has never been considered slow.
> > (joking) Don't test me, man, or I'll benchmark compile speeds on my
> > 486.
>
> You only say that because you know I threw out my 386SX25 last year :-)
My 486 still runs (barely), so if you have any reasonable benchmarks,
I'll try them for ya.
> I'd guess that FPC speed is roughly GCC minus two specific GCC problems:
> - the C disease to reparse headers again and again
> - IIRC FPC/go32v2 has AS built in, so no need to call a separate assembler.
Precompiled headers are pretty much unsupported in DOS, last I heard.
> However I don't know how big this latter difference is. When FPC got the
> internal assembler, the speed up was gigantic, but the "older" FPC model
> might not match the GCC model (specially if GCC pipes the assembler to AS),
> because afaik FPC wrote it to disk.
DJGPP's GCC doesn't support -pipe (although EMX under OS/2 does,
IIRC). However, using a RAM disk probably helps. That's what I use
when compiling (and cache).
As you probably know, OpenWatcom has a built-in assembler, and it
directly outputs to .OBJ, so usually it's much faster than GCC (e.g.
Windows). Then again, one particular C++ app I hacked a bit compiles
at almost the same speed on my P166 (DR-DOS) when using OW 1.8 or G++
3.4.4. (Even using DOS/32A vs. DOS/4GW was slower.) So it highly
depends. (Of course, I've heard that the Win32 version of OpenWatcom
uses .DLLs and is thus much faster due to less reloading.)
> I never understood this. Size was always only a side objective, even when I
> was on Dos with a 260MB HD. It was always primarily about getting things
> done. After the gigabyta era, that pretty much went away
A lot of times it doesn't matter much, that's true. And as mentioned,
smallest != fastest anymore. But there are still limits on certain
things: bandwidth, attachment size, download speed, cpu cache,
available memory (DPMI, VCPI, XMS), USB drive capacity, cluster size,
etc.
It's mainly when you *know* that things could be smaller but aren't. I
mean, why the heck does Vista / 7 need 16 GB when XP only needs like 1
or 2 GB?? Where did all that space go? I know it's been said that it
can shrink to 7 GB (gee, wow), but that's still strange to me. So a
DOS app that runs in DOS or Vista or OS/2 is (IMHO) superior to a
Vista-only app, esp. because a Vista install is so huge and expensive
(vs. FreeDOS, at least). Well, eCS ain't cheap either.
> I even assisted people with 4k and 64k demo compos at a certain point, but
> these never said it was "necessary", and never posted about their
> self-inflicted limitations in newsgroups as if it were a general, universal
> rule, something that has always greatly annoyed me in the residual TP
> circles.
Unless they are assembly programmers, the whiners aren't going to have
much of a guess at why things are larger. You can indeed use high-
level optimizations for size, but a lot of that won't make as much of
a difference unless you get down to the bare metal. Even then it's
extremely tough. Long story short: 16-bit code is always smaller, and
compilers are only oriented towards speed. And 16-bit DPMI (16 MB
limit ftw!) was never utilized much, esp. since you can't co-mingle
with 32-bit DPMI without DPMI 1.0 (which Windows never supported, even
OS/2 only goes halfway to pseudo "0.95", I think).
> > Well, 5.5 is the latest freeware version, so that's all most of us
> > have available.
>
> Wasn't it TP7 french?
I don't know. At the very least, I never investigated that too
closely. Besides, no parlais francais. ;-)
> > BTW, that's one major complaint from DOS / DJGPP users: that XP (and
> > moreso Vista, 7) crippled or broke RHIDE, which they preferred for its
> > nice interface.
>
> One can also turn it the otherway around and blame RHIDE (or its users) for
> never updating it to support windows.
DPMI *is* for Windows (and OS/2). So much work has gone into revising
DJGPP, working around bugs, being LFN-aware, etc. But there's only so
much they can do. I really don't want to blame MS, but it really is
indirectly their fault. I know they probably didn't intend that, but
that's the way it is.
Porting RHIDE to Windows doesn't help DOS, and DJGPP is only a DOS
compiler. While in theory you can have dual DOS / Win apps (or DOS /
OS2), nobody ever does. And most linkers can't handle binding those
together anyways. (Besides, RHIDE needs GCC 3.x, I think. So that
would need fixing too.) For instance, RSXNT/DJ is long since abandoned
(ten years).
> Though afaik currently the dos IDE also works on XP, and even Vista.
No, not on Vista, there is no full-screen unless you find / install
old XP drivers, which disables Aero. Apparently even disabling
"desktop composition" disables Aero (I think??), which is how I'm
setup now. Otherwise at every UAC popup (ugh), the screen would go
black for five seconds before becoming responsive. I got tired of
that, found the cause, but now I can't use Flip3D, and Chess Titans
ain't 3D (sniff, heh, like I care). Could be a driver issue on my end,
but there's not much I can do about that.
FP.EXE (IDE) works in DOSBox, but that's about it.
> I always avoided such dead ends, and moved to the next one that had at least
> some life in it, and started working. Or moved on if I didn't care enough to
> do that.
>
> Life is to precious to massively invest time to keep tools running
> apparantly nobody cares around anymore. Specially when that is time that
> isn't invested in the tool.
It just seems easier to me to have one working binary instead of ten.
There's no good reason for breaking old compatibility when it just
complicates things further. Sadly, we're all at the mercy of our
hardware and available drivers. So even the OS isn't fully to blame
(sometimes). But I don't really think C#/.NET or Java is the answer
either. Maybe virtualization is, but it's still got a ways to go.
Rugxulo
On Jan 2, 12:07 pm, Rugxulo <rugx...@gmail.com> wrote:
>
> On Jan 2, 8:43 am, Marco van de Voort <mar...@stack.nl> wrote:
>
> > On fast computers, I never saw TP code outperform the same code in 32-bit if
> > the code was non-trivial.
A 386 and a 486 are different animals, e.g. LODSB isn't much (if any)
penalty on the former but heavily slower on the latter. Granted, I've
never truly optimized for those processors, so I can't say for sure,
but in other words, what was fast then ain't as fast now. (Even GCC
2.8.x supposedly brought about 20% improvements due to Pentium
pairing, which I'm sure TP was never aware of.) And I know you know
that PentiumPros were heavily slow for 16-bit code (worse than
original Pentiums, even).
> > I never understood this. Size was always only a side objective, even when I
> > was on Dos with a 260MB HD. It was always primarily about getting things
> > done. After the gigabyta era, that pretty much went away
>
> It's mainly when you *know* that things could be smaller but aren't.
>
> > I even assisted people with 4k and 64k demo compos at a certain point, but
> > these never said it was "necessary",
>
> Unless they are assembly programmers, the whiners aren't going to have
> much of a guess at why things are larger.
Well, for instance, \demo\graph\fpctris.pp seems to be almost twice as
big with 2.4.0 vs. 1.0.10 (maybe I built it wrong??). I know it's
meant to be portable, and it IS 32-bit, pmode, high-level, so most of
that is explainable. However, keep in mind that I've seen a 360-byte
graphical tetris program (in asm, of course). ;-)
> > Though afaik currently the dos IDE also works on XP, and even Vista.
>
> No, not on Vista, there is no full-screen unless you find / install
> old XP drivers, which disables Aero. Apparently even disabling
> "desktop composition" disables Aero (I think??), which is how I'm
> setup now. Otherwise at every UAC popup (ugh), the screen would go
> black for five seconds before becoming responsive. I got tired of
> that, found the cause, but now I can't use Flip3D, and Chess Titans
> ain't 3D (sniff, heh, like I care). Could be a driver issue on my end,
> but there's not much I can do about that.
Oops, Chess Titans is indeed still 3D (although doesn't really look it
to my eyes) vs. 2D mode. But none of the other goodies (Flip3D, window
translucency) work without desktop composition. (And yes, the five
second delay is still there, before *and* after UAC pops up, so IF it
is the driver, it's still slow as heck. But I'll admit my gfx card is
fairly cheap / low-end (nVIDIA GeForce Go 6100, 1280x800, 32-bit
display mode, only 64 MB VRAM though), and it's the main factor in my
"Windows Experience" being only 2.4, heh, although the Aero part
scores 3.2, oddly, and the rest is in mid-4s.)
> FP.EXE (IDE) works in DOSBox, but that's about it.
BTW, I mean the 486 emulator from www.dosbox.com here. I've just
retested it, still won't run in normal NTVDM (it must be calling some
VESA interrupt or such, which flags Windows, ugh.) I haven't
personally used Win7 either, but I'm fairly certain it has the same
limitation. :-(
Marco van de Voort
> On Jan 2, 8:43�am, Marco van de Voort <mar...@stack.nl> wrote:
>> On 2010-01-01, Rugxulo <rugx...@gmail.com> wrote:
>>
>> FPC uses v2, apparantly I'm mistaking/outdated since go32.exe is no longer
>> in SVN
>
> From the looks of it, FPC 1.0.10 used to perhaps support v1 also
> (source/rtl/go32v1 and source/rtl/go32v2).
FPC did support go32v1, but I never saw it run. When I joined in 1997/8 iirc
it was already v2. People have played with a bunch more extenders too
(pmode, watcom), but none really stuck.
> However, nowadays it's fairly moot as NTVDM isn't regarded as having
> much of a future (even on 32-bit).
Well, it hasn been like that since w2000 didn't notably improve. And then we
are talking about 2000/2001 timeframe, and it hasn't stopped many.
This why we never supported Dos on NT based systems. We did commit decent
fixes though, which why it now at least runs on XP halfdecently.
> P.S. I could be wrong, but it seems go32v1 apps run fine on Vista but
> not on XP (you can use RSX, though). This is probably the only
> improvement I know of, offhand. ;-)
I've never run v1.
>> When I still used Dos, I used qemm, and had 64MB iirc. No problems with
>> fpc/go32v2.
>
> But did you use QDPMI or not? I think CWSDPMI is still considered
> better.
Yes.
CWSDPMI, maybe, but Qemm never gave me much trouble after v5, and one
configuration worked relatively well. 4dos-hyperdisk-qemm and quite a bit
of DV/X was my config at the time.
In practice I only had one other bootoption, one with only himem and 4dos.
Since nearly all programs that actually used memory could use higher memory
and were at least 286 extended, optimizing for maximum conventional memory
beyond having 600kb free was not terribly interesting.
>> Sure, but since they are not memory mapped, they have to be loaded first,
>> and only then paged out. And that doesn't matter for UPX, if the pages in
>> mem were compressed before or not.
>
> Well, there are other DOS extenders that were demand loaded (e.g.
> MOSS, I think), but those were rare. And even that was mostly written
> to support a commercial game on 486s, so you kinda had to have
> something (as the main .EXE had data combined with it for a 17 MB
> whopper).
I can imagine a separate dos extender being like a pager. But afaik Dos
itself always loads the binary whole? OTOH, that could be avoided by having
a PE like format (where dos also only loads the stub).
But to be honest, I don't really know in detail how this works in dos.
>> > UPX is probably more reliable than DoubleSpace or Stacker,
>>
>> Well, I never had a antivirus balking at stacker. In dos times, I kept the
>> sources that were for reference only on a small stacker drive.
>
> I think various things would have issues, but I never bothered finding
> out. The compression ratio is probably subpar anyways
Of course. But there are reasons, roughly the same reasons why I only used
solid archives for longterm archival purposes.
> (although I never converted all my .ZIPs to .7z either, so ...). Also not
> good for dual booting.
I converted them all to .Q at some point. It was the rage back then.
>> I kept one 1GB partition FAT16, and the rest FAT32 for a long time, till
>> *nix FAT32 support was mature enough. �
>
> MS patents on FAT32 still exist, which is annoying.
So I'll create my partition with my licensed XP/Vista. Big deal :-)
> Last I heard, Linux moved to a "read-only" hack, then made it where it
> would only save the LFN part, not SFN, to avoid problems. Kinda silly in
> this day and age, but oh well.
Afaik that is mostly debian and followers, not as much Linux as a whole. But
it is a problem indeed. And history seems to be repeating with the now
proposed fatex/fatplus. A different solution is using SUSE, or anything else
by Novell.
IOW the fat patents are more against the Sony/Philips/photocamera
manufacterers then against linux.
We can only hope that somepoint in the future the MS IP portfolio costs more
than it brings, and they cancel a while later. The usual Debian
holier-than-thou attitude will probably mean that FAT32 will be
postinstalled for a whole time longer.
> BTW, what I mainly meant was that several DOSes (e.g. official DR-DOS)
> never had FAT32 support (and mine never came with any beta TSRs
> either), so you're kinda stuck. In short, never ever use FAT16 with >
> 512 MB. I should've split mine up into several FAT16 partitions so
> that it would be 8k clusters instead of 16k (horrible for lots of
> small files).
I don't think I have used a non MSDOS7 version after say '98. And those were
even the exception (gaming and tests mostly), usually it was under w9x.
When I used w2000 more and more at work, I started to replace more and more
tools with win32 versions, and a few years later (2002 or so) chucked w9x
all together. It helped that the license was my employer's though, since w2k
was expensive at the time.
>> On fast computers, I never saw TP code outperform the same code in 32-bit if
>> the code was non-trivial.
>
> Well, x86-64 has no 16-bit, so DOSEMU has to emulate it.
(or chuck 16-bit. Not terribly painful. My maindesktop is 64-bit nowdays.
OTOH while I'm writing this, I'm programming a 8K, 40MIPS microprocessor in
GCC)
> But you're right, even on 486s, 32-bit code is faster because that was the
> design intention. So there usually is no comparison. Doesn't mean there
> aren't corner cases, but for the most part it does run pretty fast. DJGPP
> has never been considered slow.
All 486's that ran 32-bit code were secondary machines that typically ran
Linux or BSD. I only had Dos on my Cyrix P166+ main desktop.
>> You only say that because you know I threw out my 386SX25 last year :-)
>
> My 486 still runs (barely), so if you have any reasonable benchmarks,
> I'll try them for ya.
The only interest I would have (if I suddenly got unlimited time) is to test
the FPU emulation situation. But it could be that 2.4.0 now is PPRO (cmov)
default.
>> I'd guess that FPC speed is roughly GCC minus two specific GCC problems:
>> - the C disease to reparse headers again and again
>> - IIRC FPC/go32v2 has AS built in, so no need to call a separate assembler.
>
> Precompiled headers are pretty much unsupported in DOS, last I heard.
TC++ probably does fine.
As far as DJGPP/GCC goes, does gcc support them at all? ccached can cache
I/O time of finding/loading headers, but that is not the same as precompiled
headers afaik.
> DJGPP's GCC doesn't support -pipe (although EMX under OS/2 does,
> IIRC)
OS/2 does have decent pipes in principle, like cousin NT.
> As you probably know, OpenWatcom has a built-in assembler, and it
> directly outputs to .OBJ, so usually it's much faster than GCC (e.g.
> Windows).
So does FPC. On Windows it even has the linker built-in. Still, FPC is
slower than most older systems (GCC excepted). The focus has been more
maintainability.
> Then again, one particular C++ app I hacked a bit compiles at almost the
> same speed on my P166 (DR-DOS) when using OW 1.8 or G++ 3.4.4. (Even using
> DOS/32A vs. DOS/4GW was slower.) So it highly depends. (Of course, I've
> heard that the Win32 version of OpenWatcom uses .DLLs and is thus much
> faster due to less reloading.)
Yes. First is internal asm, 2nd not restarting for every compilation unit,
3rd is precompiled headers or (better) unit system.
> It's mainly when you *know* that things could be smaller but aren't
That still doesn't promote it from a secondary or even tertiary problem to a
primary one. Specially not with 2TB disks routinely sold. (though my
"fast" disk is only 300GB)
Everybody knows these things, and that (and why) newer versions
are bigger. Only a few percentage acts on it (and I often doubt their
reasons why)
>> I even assisted people with 4k and 64k demo compos at a certain point, but
>> these never said it was "necessary", and never posted about their
>> self-inflicted limitations in newsgroups as if it were a general, universal
>> rule, something that has always greatly annoyed me in the residual TP
>> circles.
>
> Unless they are assembly programmers, the whiners aren't going to have
> much of a guess at why things are larger.
4k was asm, 64k was TP though with mostly asm inline and custom cut down
RTL.
> Even then it's extremely tough. Long story short: 16-bit code is always
> smaller, and compilers are only oriented towards speed.
Or, more importantly, towards current tradeoffs, not the ones from 1995.
>> > Well, 5.5 is the latest freeware version, so that's all most of us
>> > have available.
>>
>> Wasn't it TP7 french?
>
> I don't know. At the very least, I never investigated that too
> closely. Besides, no parlais francais. ;-)
Speaking no, reading a bit. But even if you don't, you can dowith just
hitting the places where you know the menuentries are from memory. But maybe
it is no longer available due to the borland->embarcadero change.
>> One can also turn it the otherway around and blame RHIDE (or its users) for
>> never updating it to support windows.
>
> DPMI *is* for Windows (and OS/2).
For dos *migrational purposes* to windows and OS/2 yes. But that is
something else than for Windows and OS/2. Migration period is over.
> So much work has gone into revising DJGPP, working around bugs, being
> LFN-aware, etc. But there's only so much they can do. I really don't want
> to blame MS, but it really is indirectly their fault. I know they probably
> didn't intend that, but that's the way it is.
I'm not really a free-market bigot, but even MS does direct itself a bit in
the direction where customers are going. And (specially new) users adopted
win 3.x (which IMHO was not good enough to touch with a bargepole) en
masse. Corporate and home-. Then it was already clear that Dos was doomed,
moreover when Word started to rapidly replace WP.
Even after one year win95, already the bulk of the users didn't know dos.
The trouble with DJGPP is that their project's identity is unconditionally
bound to Dos.
> Porting RHIDE to Windows doesn't help DOS, and DJGPP is only a DOS
> compiler.
That's the real problem. If you choose to remain on a small island, there is
a fair chance you'll be left alone. Specially if the island is crumbling bit
by bit.
>> Though afaik currently the dos IDE also works on XP, and even Vista.
> No, not on Vista, there is no full-screen unless you find / install
> old XP drivers, which disables Aero.
Indeed, it refuses. Any idea what causes this? IOW which interrupt or
whatever triggers this? (djggp_setctrlC) or so?
>> Life is to precious to massively invest time to keep tools running
>> apparantly nobody cares around anymore. Specially when that is time that
>> isn't invested in the tool.
>
> It just seems easier to me to have one working binary instead of ten.
True. But why does it have to be on the most difficult target?
> (sometimes). But I don't really think C#/.NET or Java is the answer
> either. Maybe virtualization is, but it's still got a ways to go.
I think virtualization can lengthen the final axe a bit, but is no solution
either. Java is essnetially a virtualized environment.
Rugxulo
On Jan 3, 9:01 am, Marco van de Voort <mar...@stack.nl> wrote:
>
> FPC did support go32v1, but I never saw it run. When I joined in 1997/8 iirc
> it was already v2.
v2 is from 1996, so that's why. It's much more stable and compatible
although technically DJGPP v2 has no separate extender anymore, that
part is built into the lib. It only needs and can only use DPMI (which
is a "standard"). Of course, v2 apps are bigger due to this, but then
again, go32.exe is fairly bulky too (78k), but UPX only handles v2, so
it's a fair tradeoff.
> People have played with a bunch more extenders too
> (pmode, watcom), but none really stuck.
Yeah, I should try those w/ FPC, but it seems WDOSX doesn't work in
the DOS version, so I guess it must rely on Win32 RTL.
> > However, nowadays it's fairly moot as NTVDM isn't regarded as having
> > much of a future (even on 32-bit).
>
> Well, it hasn been like that since w2000 didn't notably improve. And then we
> are talking about 2000/2001 timeframe, and it hasn't stopped many.
2000 was improved over NT 4 with LFN functions, and XP was improved
over 2000 with SB emulation. And XP was most recent for a long time
(2001-2007) and was quite reliable. Vista isn't really too too bad w/
the DPMI registry hack, but the lack of full-screen a few other bugs
kinda hurt.
> This why we never supported Dos on NT based systems. We did commit decent
> fixes though, which why it now at least runs on XP halfdecently.
XP is so widespread, it makes sense to support it, if possible. That
was part of the appeal of DOS software, it ran everywhere. But
nowadays that's getting rarer and rarer (lots less Win9x or pure DOS
installs). Of course, install base alone isn't a good reason to write
software for a specific OS, but it doesn't hurt.
> I've never run v1.
I don't think you're missing much. Even I don't use many (or any?) v1
apps, off the top of my head.
> In practice I only had one other bootoption, one with only himem and 4dos.
> Since nearly all programs that actually used memory could use higher memory
> and were at least 286 extended, optimizing for maximum conventional memory
> beyond having 600kb free was not terribly interesting.
Some DOSes (e.g. DR-DOS) were better at saving low RAM than others.
And by "286 extended", I guess you mean XMS, as 16-bit pmode is fairly
rare (well, maybe more nowadays). But even XMS wasn't commonly used
with every app (lots of wimpy text editors out there).
As you know, OS/2 1.x wasn't as appealing for breaking the 640k
barrier because DOS extenders already did it. ;-)
> > Well, there are other DOS extenders that were demand loaded (e.g.
> > MOSS, I think), but those were rare.
>
> I can imagine a separate dos extender being like a pager. But afaik Dos
> itself always loads the binary whole? OTOH, that could be avoided by having
> a PE like format (where dos also only loads the stub).
MOSS was ELF-based, and it definitely didn't need 17 MB of RAM because
it claimed to run on a lowly 486 w/ 8 MB. I guess DOS ignores the
overlay part (a.out) and only loads the extender proper (moss.exe),
which handles the dirty work.
> But to be honest, I don't really know in detail how this works in dos.
And I do?? I think only the authors of said tools would really know!
(It's complicated!)
> Of course. But there are reasons, roughly the same reasons why I only used
> solid archives for longterm archival purposes.
Semi-solid (or with recovery info) is best although in reality I never
bother (probably should, though).
> > (although I never converted all my .ZIPs to .7z either, so ...). Also not
> > good for dual booting.
>
> I converted them all to .Q at some point. It was the rage back then.
Quantum? Too slow, there are much faster options (esp. these days).
> > MS patents on FAT32 still exist, which is annoying.
>
> So I'll create my partition with my licensed XP/Vista. Big deal :-)
Except they only let you create FAT32 w/ 32 GB max size (yet another
"father knows best" limit). Not that I can imagine wanting more than
that for pure DOS, but still .... And it's not the FAT32 itself that
is patented, just certain additions (e.g. VFAT LFN hack).
> I don't think I have used a non MSDOS7 version after say '98. And those were
> even the exception (gaming and tests mostly), usually it was under w9x.
Well, DR-DOS kinda gave up the ghost (at least in development), so it
stagnated. Win9x only ran atop MS-DOS anyways (without some private
hack that DR never released). And DR / Caldera / Lineo changed hands
too many times. And Linux is more popular. Strange that DOS (and
related software) is considered so dead and useless and yet held onto
so tightly at the same time.
> When I used w2000 more and more at work, I started to replace more and more
> tools with win32 versions, and a few years later (2002 or so) chucked w9x
> all together. It helped that the license was my employer's though, since w2k
> was expensive at the time.
Win2k was never for home users, hence why XP is more popular. 2k / XP
aren't bad, but it heavily annoys me when apps won't run anywhere else
(e.g. Win98SE) and/or require specific versions of MSVCRT. I don't see
how that's better than being ultra-compatible. Why would anybody want
to be less compatible?? But they do!
> >> On fast computers, I never saw TP code outperform the same code in 32-bit if
> >> the code was non-trivial.
>
> > Well, x86-64 has no 16-bit, so DOSEMU has to emulate it.
>
> (or chuck 16-bit. Not terribly painful. My maindesktop is 64-bit nowdays.
> OTOH while I'm writing this, I'm programming a 8K, 40MIPS microprocessor in
> GCC)
16-bit isn't evil or useless, but yeah, almost nobody prefers it. It's
not that it's too horrible to convert, but then again, in such a
closed environment (Windows), it really is asking a lot to make people
dump all their old software. Sure, some of it is extremely crusty and
should be retired, but there are more than a few gems in there worth
preserving. Just being 32-bit (or 64-bit) doesn't make software better
(or good, even).
> As far as DJGPP/GCC goes, does gcc support them at all? ccached can cache
> I/O time of finding/loading headers, but that is not the same as precompiled
> headers afaik.
No support for precompiled headers, last I heard. No -pipe, no
threading, etc. It pretty much just relies on RAM drive for temps and
software cache.
> > It's mainly when you *know* that things could be smaller but aren't
>
> That still doesn't promote it from a secondary or even tertiary problem to a
> primary one. Specially not with 2TB disks routinely sold. (though my
> "fast" disk is only 300GB)
I don't think 2 TB is quite standard yet. That's very high end. I
don't see ads with new computers with anywhere near that much.
Besides, isn't the MBR limited to like 1.5 TB or such?? (I forget....)
> Everybody knows these things, and that (and why) newer versions
> are bigger. Only a few percentage acts on it (and I often doubt their
> reasons why)
Obviously FPC could definitely use lots more testers, contributors,
etc. I'm just afraid I don't have much to offer.
> >> One can also turn it the otherway around and blame RHIDE (or its users) for
> >> never updating it to support windows.
>
> > DPMI *is* for Windows (and OS/2).
>
> For dos *migrational purposes* to windows and OS/2 yes. But that is
> something else than for Windows and OS/2. Migration period is over.
It wasn't migrational (at least, in theory), it was meant for a way
for all the various extenders to "get along" with each other and esp.
with multitasking environments.
> The trouble with DJGPP is ...
>
> read more »
Oy! To be continued ....
Rugxulo
On Jan 3, 9:01 am, Marco van de Voort <mar...@stack.nl> wrote:
>
> I'm not really a free-market bigot, but even MS does direct itself a bit in
> the direction where customers are going. And (specially new) users adopted
> win 3.x (which IMHO was not good enough to touch with a bargepole) en
> masse. Corporate and home-. Then it was already clear that Dos was doomed,
> moreover when Word started to rapidly replace WP.
I think you're mistaken. Win 3.0 came out in 1990, and that's where
DPMI actually debuted. In 386 enhanced mode you could finally
multitask several DOS 32-bit pmode apps. That was not possible with OS/
2 (until 2.0 in 1992) because (allegedly) IBM was stuck on supporting
286s (which isn't really that bad a thing). So MS and IBM parted ways.
If you think DOS was doomed, you forgot that Win3.x ran atop DOS (even
DR-DOS), and even Win9x ran atop MS-DOS 7. So DOS was far from dead,
just hidden because MS prefers GUIs as the way of the future (probably
inspired by the original Mac). Sure, NT has no DOS because it's fully
32-bit, written from scratch, very portable (initially). They probably
would've switched to it exclusively much earlier if hardware could
keep up with the higher software requirements. Until Win95, you could
really only write 32-bit apps in DOS (well, unless you count Win32s,
or did that only come out later? No, it stood for WinNT "s"ubset,
right?)
> Even after one year win95, already the bulk of the users didn't know dos.
I disagree. The main cliche to mention here would be Quake (late 1996)
using DJGPPv2 (2.00beta3, GCC 2.7.2). Or any DJGPP tools themselves,
even, which kept being updated.
It doesn't mean DOS didn't have deficiencies (esp. drivers), but you
can't say "Linux / FreeBSD is teh rox0rz" without admitting that
FreeDOS could legitimately be extended in similar fashion too. "Oh,
but then it wouldn't be DOS." And yet Linux 0.001 still counts as
Linux?!? What about everything prior to 2.2? 2.4? x86-64? Is it still
Linux?? Apparently so.
> The trouble with DJGPP is that their project's identity is unconditionally bound to Dos.
That's unavoidable, esp. since that's all DJGPP ever was for: DOS.
Originally DJGPPv1 used a.out, but then (1992?) they switched to COFF.
"Best available format at the time" is what I've heard. And Linux
didn't switch to ELF until 1996 or so. WinNT variants all use PE/COFF,
so in theory it should be possible to make dual .EXEs. (EMX [VCPI]
used a.out, RSX was the DPMI rewrite of EMX by someone else, and RSX
could also run DJGPPv1 apps.) Japheth mentions how to make PEs for HX
with DJGPP. CWS himself ran an aborted experiment in 1995 to make
dual .EXEs (but a Texas flood washed away his efforts). RSXNT/DJ
succeeds but is old and abandoned. The only other example I can think
of in a similar vein is Josh Vanderhoof's (?) cross ELF tools (e.g.
xlink.com or xlink.exe can run same ELF under DOS, Windows, etc). Oh,
and Daniel Borca's fork of DJGPP 2.04 to ELF (GCC 4.0.1, BinUtils
2.16) still uses the DJGPP DOS C library (for COFF or ELF) but
optionally (ELF only) can create its own .so files or use .so files
from Linux.
> > Porting RHIDE to Windows doesn't help DOS, and DJGPP is only a DOS
> > compiler.
>
> That's the real problem. If you choose to remain on a small island, there is
> a fair chance you'll be left alone. Specially if the island is crumbling bit
> by bit.
MS either won't or (more likely) can't fix NTVDM. RHIDE no longer
works (whereas it worked fine for ten years or so). So now the only
option in your eyes is to drop DOS, DJGPP, etc. and move exclusively
to Win32? And build RHIDE exclusively for Win32? If someone crashes
into your car, do you go immediately buy a new one (and make sure it's
completely different: truck, perhaps?)?
> >> Though afaik currently the dos IDE also works on XP, and even Vista.
> > No, not on Vista, there is no full-screen unless you find / install
> > old XP drivers, which disables Aero.
>
> Indeed, it refuses. Any idea what causes this? IOW which interrupt or
> whatever triggers this? (djggp_setctrlC) or so?
No idea, probably int 10h somewhere (even VESA BIOS id check would do
it, ugh).
> > It just seems easier to me to have one working binary instead of ten.
>
> True. But why does it have to be on the most difficult target?
What do you suggest instead???
Marco van de Voort
> 286s (which isn't really that bad a thing). So MS and IBM parted ways.
> If you think DOS was doomed, you forgot that Win3.x ran atop DOS (even
> DR-DOS), and even Win9x ran atop MS-DOS 7.
Which meant absolutely nothing from most users perspective. Is like a Mac
with Forth based bootstrap not making every Mac users Forth experts. (or
even know what it is)
And yes, DPMI was originally created to make >640kb use over a range of OSes
possible. But mostly for their dos compatibility modes.
> Until Win95, you could really only write 32-bit apps in DOS (well, unless
> you count Win32s, or did that only come out later?
No idea.
>> Even after one year win95, already the bulk of the users didn't know dos.
>
> I disagree. The main cliche to mention here would be Quake (late 1996)
> using DJGPPv2 (2.00beta3, GCC 2.7.2). Or any DJGPP tools themselves,
> even, which kept being updated.
Quickly followed by quake '95. That says enough.
> It doesn't mean DOS didn't have deficiencies (esp. drivers), but you
> can't say "Linux / FreeBSD is teh rox0rz" without admitting that
(I can't even decrypt that, leet speak is beyond me)
> FreeDOS could legitimately be extended in similar fashion too. "Oh,
> but then it wouldn't be DOS."
The point is nobody cared.
> And yet Linux 0.001 still counts as Linux?!? What about everything prior
> to 2.2? 2.4? x86-64? Is it still Linux?? Apparently so.
You got a point there. It also has been one of the weaknesses of Linux, the
absense of long runnable binaries.
>> That's the real problem. If you choose to remain on a small island, there is
>> a fair chance you'll be left alone. Specially if the island is crumbling bit
>> by bit.
>
> MS either won't or (more likely) can't fix NTVDM. RHIDE no longer
> works (whereas it worked fine for ten years or so). So now the only
> option in your eyes is to drop DOS, DJGPP, etc. and move exclusively
> to Win32?
Stronger. I think that should have been done in 2000-2005 somewhere.
IOW I think it is too late now, after the large gap. Even if sb really
invests a lot of time, most of the users that one could have kept
(educatioal, or only for the fun of it) moved one.
Same happened with FPC textmode IDE more or less. Naot DOS, but related to
the same group.
> And build RHIDE exclusively for Win32? If someone crashes into your car,
> do you go immediately buy a new one (and make sure it's completely
> different: truck, perhaps?)?
If the old car type was somehow doomed, yes of course! Not because I would
want change, just for practical reasons.
>> True. But why does it have to be on the most difficult target?
>
> What do you suggest instead???
Stop flogging the dead horse. Choose anything practical, and somewhat where
your investments NOW are not lost.
Rugxulo
On Jan 3, 3:56 pm, Marco van de Voort <mar...@stack.nl> wrote:
> On 2010-01-03, Rugxulo <rugx...@gmail.com> wrote:
>
> > 286s (which isn't really that bad a thing). So MS and IBM parted ways.
> > If you think DOS was doomed, you forgot that Win3.x ran atop DOS (even
> > DR-DOS), and even Win9x ran atop MS-DOS 7.
>
> Which meant absolutely nothing from most users perspective.
Sure it does, esp. (and only) if you want to run DOS programs! And
that's considered a valuable feature except by very young kids and old
snobs.
> And yes, DPMI was originally created to make >640kb use over a range of OSes
> possible. But mostly for their dos compatibility modes.
Thank 386's V86 mode for that. That was a big improvement over the
286. Too bad AMD64 pretty much makes the same mistake.
> >> Even after one year win95, already the bulk of the users didn't know dos.
>
> > I disagree. The main cliche to mention here would be Quake (late 1996)
>
> Quickly followed by quake '95. That says enough.
Only because Carmack didn't think Quake 2 for DOS was worth it *to him
personally*, esp. for networking and gfx drivers (esp. hardware
acceleration). It could've been done, though.
Hexen2 is based upon Quake 1 but oddly enough never had a DOS (or
Linux or *BSD) port. But the engine was open sourced, so some guys
have "ported it back" to DJGPP etc: Hammer of Thyrion. Except for no
music (yet), it works well !
> > FreeDOS could legitimately be extended in similar fashion too. "Oh,
> > but then it wouldn't be DOS."
>
> The point is nobody cared.
Obviously somebody cared or we wouldn't have WINE, DOSBox, FreeDOS,
DOSEMU, DJGPPv2, OpenWatcom, HX, etc.
> > And yet Linux 0.001 still counts as Linux?!? What about everything prior
> > to 2.2? 2.4? x86-64? Is it still Linux?? Apparently so.
>
> You got a point there. It also has been one of the weaknesses of Linux, the
> absense of long runnable binaries.
It doesn't have to be that way, though.
> > MS either won't or (more likely) can't fix NTVDM. RHIDE no longer
> > works (whereas it worked fine for ten years or so). So now the only
> > option in your eyes is to drop DOS, DJGPP, etc. and move exclusively
> > to Win32?
>
> Stronger. I think that should have been done in 2000-2005 somewhere.
Why, what happened then? The main "problems" were the fact that you
couldn't natively resize the blasted NTFS "hog the whole drive" on XP
systems as well as NTVDM bugs (whereas it worked fine before). That's
not a good reason to drop DOS support, that's just the easiest and
laziest option. So all that means is people are lazy.
Everybody accepted XP, and it was successful. Too bad Vista broke some
stuff and was slower and heavier. Now XP is almost obsolete, but good
luck telling people to drop that. In other words, when people find
something that works, they stick to it. In other words, if even XP is
obsoleted, what good is any software?
> IOW I think it is too late now, after the large gap. Even if sb really
> invests a lot of time, most of the users that one could have kept
> (educatioal, or only for the fun of it) moved one.
People move on all the time, it's their short attention span. Doesn't
reflect on any technical merit. PAE would probably be better utilized
these days (better compatibility) than 64-bit, but MS doesn't allow
that "due to driver bugs".
> >> True. But why does it have to be on the most difficult target?
>
> > What do you suggest instead???
>
> Stop flogging the dead horse. Choose anything practical, and somewhat where
> your investments NOW are not lost.
I expected you to say FreeBSD 64-bit here. Instead you chose a very
vague and pessimistic statement. Sorry, but these days all investments
in software are almost a total loss when people don't legitimately
work towards keeping things compatible, esp. when a lot of it is more
arrogance or sloppiness instead of true technical deficiencies. (And I
am not implying MS here.)
Dan McGrath
wrote:
>use other stuff (XMS, VCPI). Mixing v1 and v2 apps is rare since most
>got updated or are redundant. (FYI, the Desqview/X toolkit used DJGPP
There is no such word as "rare".
- Dan
--
Daniel G. McGrath
Binghamton, New York
e-mail: dmcg6174[AT]gmail[DOT]com