Back to home page

DOS ain't dead

Forum index page

Log in | Register

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

Homepage

Usono,
24.02.2009, 07:06

@ DOS386

FPC: 7-Zip or UPX ; TC++ pros and cons

> Funny. All executables inside FPC package are UPX'ed and I shouldn't
> it then :clap:
>
> What about banning UPX and reducing package size in next release,
> see msg=5374 ? :-)

First of all, switching to 7-Zip has been vaguely discussed here before (by Steve and marcov), but it wasn't considered realistic due to potential platform issues, portability concerns, lack of testing, as well as no Pascal srcs for such (unlike Zip).

Secondly, they could stop using UPX, esp. if they all hate UPX so much, but it would increase download size ... although UPX's best uses LZMA anyways, so switching to 7-Zip would offset that.

(As for UPX license conflict, I don't know of any, but using UPX-UCL can easily fix that, which is 100% same compression for LZMA, only very vaguely worse ratio for UCL instead of closed-src NRV.)

Here's what I recently packaged for FreeDOS (if anybody here cares, highly doubt it):

http://rugxulo.googlepages.com/upx-uclx.zip
http://rugxulo.googlepages.com/upx-ucls.zip

> > If DJGPP really stops, Dos is dead.
>
> They stopped DOS support 10 years ago. Are you able to use the BUGzilla
> now ? Maybe someone should port GCC to DOS ASAP :hungry:

Eh? No, I think they only stopped bothering to SFN-ize the srcs. Otherwise, everything still works. (Besides, 2.04 beta is from 2003, so that's "only" five years, heh.)

> > Turbo C++ 1.01 is "dead" but still used by FreeDOS many years after
>
> no C99

Nor C++0x, boo hoo.

> > + runs on 16-bit cpus
>
> heh, unique ... :-|

One of the only full ANSI C freeware ones I know of. All the others are only subsets, thus not as good.

> > - DOS only (no cross compiling supported)
>
> This is not a con :-P

It is if you want to compile from x86-64 without DOSEMU. Or if you wanted to target other OSes, which are becoming more common every day.

> > - no newer C++ features (generics, templates, etc.)
>
> nor C99

To be honest, even GCC has imperfect C99 support. And most people don't want or use it anyways (ahem, MSVC).

> > - 186/286 optimizations at most (useless for 99% of the world)
>
> What did you expect from a 16-bit compiler ? 8086 is enough :-)

AFAICT, even 286 is not really supported, only 186. I dunno, it's still good, just less than optimal (e.g. OpenWatcom produces faster code).

> > - OpenWatcom is better in most ways (but needs 386+ to host)
>
> + the bloat :-(

You mean the compiler overall? Blame 386+ opcodes or (heh) use UPX. ;-)

> > Besides, there even a DOS extender that works with it
>
> pulled one more coffin from its grave ? :lol3: What's unique on it ?

What's unique? It works with TC++, even virtual memory. Not enough? ;-)

marcov(R)

24.02.2009, 10:40

@ DOS386

Compatibility woes / deprecation of UPX

> > > > I don't see the point.
> > > Me neither. Why all FreePASCAL releases up to 2.2.2 are that heavily
> > > infiltrated with UPX and that absurdly bloated because of this.
> > Because that something is included, it doesn't mean you should routinely
> use it.
>
> Funny. All executables inside FPC package are UPX'ed and I shouldn't it
> then :clap:

Can you imagine how long that package script hasn't been updated....

> What about banning UPX and reducing package size in next release, see
> msg=5374 ? :-)

I'm all for it: Submit a proposal for a new package system, run a few beta's, make sure they are well tested.

cm(R)

Homepage E-mail

Düsseldorf, Germany,
24.02.2009, 10:46

@ Rugxulo

186 or 286

> > > - 186/286 optimizations at most (useless for 99% of the world)
> >
> > What did you expect from a 16-bit compiler ? 8086 is enough :-)
>
> AFAICT, even 286 is not really supported, only 186.

In fact, the 286 didn't add much to the Real Mode instruction set. Most extensions usually called 286 are in fact 186 extensions.

---
l

marcov(R)

24.02.2009, 11:11

@ cm

186 or 286

> > > > - 186/286 optimizations at most (useless for 99% of the
> world)
> > >
> > > What did you expect from a 16-bit compiler ? 8086 is enough :-)
> >
> > AFAICT, even 286 is not really supported, only 186.
>
> In fact, the 286 didn't add much to the Real Mode instruction set. Most
> extensions usually called 286 are in fact 186 extensions.

Support doesn't really have to be about adding instructions. It can also be instruction choice. (and with later CPUs: scheduling)

marcov(R)

24.02.2009, 11:32

@ Rugxulo

Compatibility woes / deprecation

> The Pentium had been advertised as having a 64-bit bus (or whatever), not
> to mention MMX on later models technically being 64-bit. I know that's not
> the same thing, but that's how it was spun in some cases.

Yes, but they fooled nobody serious with that :-)

> > And in general the P4 depended more on "P4 optimized code" than P-III.
> > Athlon was even less picky about how the code was optimized.
>
> Well, they broke some common optimizations used in the past due to
> architectural differences. Of course I think all cpus are like that, even
> AMDs (from my limited reading of the optimization hints in tech docs).

Yes, but the problem was that the penalties were so steep because the P4 with its deep pipelines was so different.

IOW the difference is that you noticed such things inabout general code by normal compilers. Not last cycle work with the intel compiler.

> That's what I meant, home use. Of course, even the first 64-bit Opterons
> were server only, right?

And workstation. But the workstation pendant Athlon64 predates Opteron, so it is not the same.

(SSE/MMX)
> > It isn't, but it shouldn't be overrated. Rule of thumb, it is useless
> > unless you specifically code for it.
>
> I mean, it just feels somewhat useless since it's weird and involves
> rewriting code manually (although this is a perfect example that "compiler
> outperforms humans" isn't always true since most compilers can't vectorize
> worth a damn).

Note that we currently have exactly this same discussions again about cores. The same advocates that said that "better compilers will solve this" are at it again.

Of course it is not entirely the same, but the pure compiler part is IMHO. But the line is blurred that frameworks often can do something (hiding parallelism for the user)

> GCC has "-mfpmath=", which allows 387, sse, or both. But I'm not sure it
> helps (yet?), highly experimental I think.

FPC has {$FPUTYPE SSE2}

> > Where do you get that? One still installs DDR (1,2,3) in pairs for
> optimal
> > performance, and each is 64-bit. So afaik mem bandwidth is still
> 128bit.
> > (unless you use several QPI/HT)
>
> I mean SSE bandwidth (or so I heard).

Ah ok.

> Anyways, I also read somewhere that Core 2 can (optimally) do four
> instructions per clock unlike AMD at max. three. That alone is pretty
> good, so raw clock speed doesn't matter as much as previously (e.g. 486 or
> 586).

Yes, but only if they are parallizable, and 3-4 loads/stores per clock aren't.
Note that both Phenom II and i7 have now 1 cycle L1 caches, which might improve this a bit. (when not read lineairly)

> Maybe not on Windows for make, bash, gcc, etc, but DOS has no issues.

It's more important on Windows true. And Dos has maximal partition limits? How much storage can you use on a single HD on pure dos? 24 partitions of 2GB or so?

> The only reason to not use something old is if the new improves in
> every way, which is hardly typical.

That is not correct. If it works better/easier over the whole line is enough. Otherwise I would always remain stuck with something old because it is "better" on one not terribly important point.

> Pros:
> + small

Not an advantage per se.

> + fast (even can use EMS or XMS for even faster speeds)

For me 32-bit binaires were always faster.

> + 16-bit code (which GCC still lacks)
> + runs on 16-bit cpus
> + all models: tiny through huge
> - 186/286 optimizations at most (useless for 99% of the world)

Not a requirement. Don't have anything in use below XP2000+

> + supports ANSI C and C++ AT&T 2.0

I'm not a C programmer.

> + nice IDE
> + nice help / function reference

I use FPC's IDE. Works fine. Am improving the help, but it is huge.

> Cons:
> - no sources

Less important if it works right. But for runtime parts sources are a non negotiable requirement.

> - DOS only (no cross compiling supported)

Useless :-)

> - no newer C++ features (generics, templates, etc.)

Those would be the only reason to use C++ in the first place.

> - OpenWatcom is better in most ways (but needs 386+ to host)
>
> Besides, there even a DOS extender that works with it
> (Swallow

Pmode works with FPC too. Likewise untested in recent years.

cm(R)

Homepage E-mail

Düsseldorf, Germany,
24.02.2009, 11:56

@ marcov

MS-DOS partition limits

> > Maybe not on Windows for make, bash, gcc, etc, but DOS has no issues.
>
> It's more important on Windows true. And Dos has maximal partition limits?
> How much storage can you use on a single HD on pure dos? 24 partitions of
> 2GB or so?

If "pure DOS" implies "retail MS-DOS", yes. Note that you can't store all these partitions on a single disk because retail MS-DOS never supported LBA, so it accesses only the first 8 GiB of all disks. Most modern DOS versions (even later MS-DOS) however support LBA and FAT32 (some even support up to 32 drive letters instead of 26 ;-)).

---
l

marcov(R)

24.02.2009, 18:38

@ cm

MS-DOS partition limits

> > How much storage can you use on a single HD on pure dos? 24 partitions
> of
> > 2GB or so?
>
> If "pure DOS" implies "retail MS-DOS", yes.

Yes and no. I also include the w9x doses booted in dos. (so without w9x running).

> Note that you can't store all
> these partitions on a single disk because retail MS-DOS never supported
> LBA, so it accesses only the first 8 GiB of all disks. Most modern DOS
> versions (even later MS-DOS) however support LBA and FAT32 (some even
> support up to 32 drive letters instead of 26 ;-)).

Is there a canonical list with most important properties somewhere?

Rugxulo(R)

Homepage

Usono,
24.02.2009, 19:29

@ marcov

MS-DOS partition limits

> > > How much storage can you use on a single HD on pure dos? 24 partitions
> > of
> > > 2GB or so?
> >
> > If "pure DOS" implies "retail MS-DOS", yes.
>
> Yes and no. I also include the w9x doses booted in dos. (so without w9x
> running).

Early versions of Win95 didn't support LBA or FAT32, I think corrected in OSR2 or so. Anyways, here's what the FreeDOS Wikipedia page says:

"FAT32 is fully supported, even booting from it. Depending on the BIOS used, as many as four LBA hard disks up to 128 GB, or even 2 TB in size are supported."

> > Note that you can't store all
> > these partitions on a single disk because retail MS-DOS never supported
> > LBA, so it accesses only the first 8 GiB of all disks. Most modern DOS
> > versions (even later MS-DOS) however support LBA and FAT32 (some even
> > support up to 32 drive letters instead of 26 ;-)).
>
> Is there a canonical list with most important properties somewhere?

Comparison of x86 DOS OSes

Rugxulo(R)

Homepage

Usono,
24.02.2009, 19:46

@ marcov

Compatibility woes / deprecation

> > The only reason to not use something old is if the new improves in
> > every way, which is hardly typical.
>
> That is not correct. If it works better/easier over the whole line is
> enough. Otherwise I would always remain stuck with something old because
> it is "better" on one not terribly important point.

Well, for instance, I use HHsed a lot, and it's old and not as good as GNU sed, for instance. BUT, it's much smaller, easier to build, and actually faster (no thanks to 16-bit code, though). Doesn't mean I can't still use GNU sed sometimes, but hey, if it ain't broke, why fix it?

> > Pros:
> > + small
>
> Not an advantage per se.

True, I take it back, but it's not exactly a disadvantage either. ;-)

> > + fast (even can use EMS or XMS for even faster speeds)
>
> For me 32-bit binaires were always faster.

True again, esp. since even the 486 runs 32-bit code faster. In simple benchmarks, Blair's 16-bit C MD5SUM is lots slower than DOS386's FreeBASIC MD5 tool.

But I actually meant the compiler itself is fast ("turbo").

> > + 16-bit code (which GCC still lacks)
> > + runs on 16-bit cpus
> > + all models: tiny through huge
> > - 186/286 optimizations at most (useless for 99% of the world)
>
> Not a requirement. Don't have anything in use below XP2000+

Well, just saying, GCC doesn't properly support 16-bit code yet (although GAS mostly does, from what I've read). Rask was/is? working on something, and even DJ himself hacked 2.7.2.3 "back in the day" to semi-working 16-bit status. So you have to use something other than GCC.

It's been said that 16-bit is only needed for boot loaders, but obviously some OSes (DOS, ELKS) still use it too. Personally, I think "anything that works" is fine, but some people are offended by 16-bits (although mostly due to segments and their quirks, I think).

> > + supports ANSI C and C++ AT&T 2.0
>
> I'm not a C programmer.

Neither am I really. Note that I also don't know any Pascal, but I wouldn't mind learning some eventually. (IOW, I'm not a purist.)

> > + nice IDE
> > + nice help / function reference
>
> I use FPC's IDE. Works fine. Am improving the help, but it is huge.

I don't actually use TC's IDE much except on rare occasion to look up some function. I like TDE.

> > Cons:
> > - no sources
>
> Less important if it works right. But for runtime parts sources are a non
> negotiable requirement.

Well, if this were a deal breaker, I'd switch exclusively to OpenWatcom. But it's not.

> > - DOS only (no cross compiling supported)
>
> Useless :-)

Less useless with DOSBox, DOSEMU + FreeDOS, 32-bit Windows, etc.

> > - no newer C++ features (generics, templates, etc.)
>
> Those would be the only reason to use C++ in the first place.

Not really. Some (few) people still use C++ as a glorified "C with classes". A C++ subset is realistically better than nothing.

> > Besides, there even a DOS extender that works with it
> >
> (Swallow
>
> Pmode works with FPC too. Likewise untested in recent years.

Too busy porting to Nintendo DS? :-D

cm(R)

Homepage E-mail

Düsseldorf, Germany,
24.02.2009, 22:41

@ marcov

MS-DOS partition limits

> > > How much storage can you use on a single HD on pure dos? 24 partitions
> > of
> > > 2GB or so?
> >
> > If "pure DOS" implies "retail MS-DOS", yes.
>
> Yes and no. I also include the w9x doses booted in dos. (so without w9x
> running).

Then the answer is no. As far as I remember MS-DOS 7.00 (from Windows 95) has LBA support; MS-DOS 7.10 (from Windows 95 OSR2, Windows 98 and 98 SE) has both LBA and FAT32 support. (MS-DOS 8.00 from Windows Me [and on the Windows XP MS-DOS bootdisk] seems mostly a hacked 7.10 with some kernel compression.)

---
l

DOS386(R)

25.02.2009, 03:18

@ Rugxulo

FPC: 7-Zip or UPX ; TC++ pros and cons bloated WATCOM

> switching to 7-Zip has been vaguely discussed here before
> (by Steve and marcov), but it wasn't considered realistic due to potential
> platform issues, portability concerns, lack of testing, as well as no
> Pascal srcs for such (unlike Zip).

I indeed understand this type of purism, but "argument" is invalid nevertheless, there is no PASCAL source of UPX either.

> Secondly, they could stop using UPX, esp. if they all hate UPX so
> much, but it would increase download size

Did you test before boasting ? In my test the size got reduced by factor 2 !!! :surprised:

(WATCOM)

> You mean the compiler overall?

YES.

> Blame 386+ opcodes or (heh)

NO.

> use UPX.

NO, see above.

> What's unique? It works with TC++, even virtual memory. Not enough?

Does it work on 8086 ?

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

Rugxulo(R)

Homepage

Usono,
25.02.2009, 09:29

@ DOS386

FPC: 7-Zip or UPX ; TC++ pros and cons bloated WATCOM

> I indeed understand this type of purism, but "argument" is invalid
> nevertheless, there is no PASCAL source of UPX either.

True.

> > Secondly, they could stop using UPX, esp. if they all hate UPX
> so much, but it would increase download size
>
> Did you test before boasting ? In my test the size got reduced by factor 2
> !!! :surprised:

With 7-Zip, yes. By reducing UPX alone and keeping .ZIP, not so much. (No, I didn't test, obviously.)

> > What's unique? It works with TC++, even virtual memory. Not enough?
>
> Does it work on 8086 ?

No. You cannot use anything besides real EMS on an 8086. As such, neither XMS, VCPI, nor DPMI are available.


----------------------------------
SWALLOW v1.0 - a DOS-Extender to
write own Protected Mode programs
with TP 6/7, TC++ 1.0 or BC++ 3.1.
It provides virtual memory and
supports 32 bit assembler code.
Card software except the sources
of the extender itself.
386 required.
----------------------------------


EDIT: Found a minor update (1.01) here.

marcov(R)

25.02.2009, 12:58

@ DOS386

FPC: 7-Zip or UPX ; TC++ pros and cons bloated WATCOM

> > switching to 7-Zip has been vaguely discussed here before
> > (by Steve and marcov), but it wasn't considered realistic due to
> potential
> > platform issues, portability concerns, lack of testing, as well as no
> > Pascal srcs for such (unlike Zip).
>
> I indeed understand this type of purism, but "argument" is invalid
> nevertheless, there is no PASCAL source of UPX either.

UPX doesn't run during install.

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