DOS ain't dead

> -O3 won't do much on a program that only contains one statement
> (writeln('hello world');)
>
> This is very true. This is why I changed the target to a GREP utility.
> These programs have a definite use.

DJGPP GNU Grep 2.11 (2.03p2, aka /current/, its latest / last available version):

fgrep.exe 173568
egrep.exe 245248
grep.exe 246784
greppcre.exe 332800

DJGPP GNU Grep 2.11 (2.04, aka /beta/):

fgrep.exe 243712
egrep.exe 315904
grep.exe 316928
greppcre.exe 403456

DJGPP GNU Grep 2.20 (2.04, aka /beta/):

egrep.exe and fgrep.exe are (binary, 2048 bytes) symlinks to the main grep.exe, which is 1,383,936 bytes.

And old XGREP.COM (written in 8086 assembly) is 3380 bytes.

As you probably know, DOS "find" is more or less a simple grep clone without the regexp (but see modern Windows' FINDSTR). Latest FreeDOS FIND 3.0a with LFN support is (unpacked from UPX) only 13528 bytes (but 16-bit code is often smaller, max instruction size for 8086 and 286 is 6 and 10 bytes, respectively).

Obviously XGREP doesn't support filename globbing nor LFNs nor PCRE. And DJGPP 2.04 supports "full" symlinks (thus not only for .EXEs), which bloats up the binaries more than normal, even for same version. And note that these DJGPP binaries were probably compiled for speed (-O2) not size (-Os).

> This is very true. This is why I changed the target to a GREP utility.
> These programs have a definite use.

Another obvious comparison is assembly, which is as low a level as you can go.

Even old old (DJGPP 2.x) BinUtils AS 2.6 (1996) is 319488 bytes. GAS 2.19 circa 2008 (from 2.03p2) is 834048 bytes. Latest AS 2.24r2 (from 2.04 /beta/) is 1,265,152 bytes.

Venksi's ASM.COM (8086 only, binary output only, assembles itself) is only 7297 bytes (uncompressed).

FASM is a more robust, standalone assembler, so it's a better tool. Totally written in itself, 32-bit host but supports all targets (16-bit, 32-bit, 64-bit) and several output formats (COFF, ELF, MZ, PE) and literally all (AFAIK) current Intel and AMD instructions.

Here is latest 1.71.21:

93089 fasm (Linux native version)
95452 fasm.exe (DOS version)
102400 fasmcon.exe (Win32 console version)
120660 fasmd.exe (DOS version plus IDE, aka text editor and calculator)
143872 fasmw.exe (Win32 version plus GUI IDE)

Note that this is 100% assembly, no HLLs used! It's not even UPX'd! And honestly, a lot of that is data, even, since he's supporting all kinds of weird stuff (AVX, heh). Just for quick comparison to itself, 1.60 (circa 2005) for DOS was only 65163 bytes.

> -O3 won't do much on a program that only contains one statement
> (writeln('hello world');)
>
> This is very true. This is why I changed the target to a GREP utility.
> These programs have a definite use.
>
> I was just trying to find out about FP when the very next post criticized
> my floppy drive.

A few years ago, I got the crazy idea to cram DJGPP on a 1.44 MB floppy. Of course it won't actually fit, so you have to compress it. What do you use? I originally used UHarc (needing 24 MB to unpack, and very slow), then later migrated to 7-Zip (and tiny 7zdecode, needing only roughly 6 MB to unpack, plus much faster). However, the "newest" DJGPP I could cram on there was 2.95.3 and BinUtils 2.16.1 with DJGPP libc 2.03p2 and a few other tools (make, ar, ed, rm). I couldn't fit strip, but "ld -s" does the same thing. Also, including "ed" was more or less my attempt at providing both text editor plus grep plus sed all-in-one.

I ended up recompiling some stuff (IIRC, with GCC 4.2.3) for smaller size since usually they don't use "-Os" but prefer "-O2". Anyways, for comparison, stock GCC2953B.ZIP's CC1.EXE was 1,621,504 bytes where my recompile was 1,388,032. GCC 3.4.4's CC1.EXE (2.03p2?) was 4,212,224. Latest (2.04 /beta/ only) GCC 4.9.0's CC1.EXE is 15,596,544.

But keep in mind that latest 4.x does a lot more than 2.x or even 3.x ever did. I can already hear Marco saying, "15 MB is peanuts." Honestly, the real problem for a tool like that isn't disk footprint, nor even speed, but RAM usage. It uses much much more than 15 MB of RAM, optimizations or not, for data, not its own measly footprint. But even for its footprint, in theory, the DPMI host could demand page in the .EXE. Unfortunately, most (e.g. CWSDPMI) don't do that and just load the whole thing in one lump.

And BTW, nobody ever told me that wasting time on such a "EZ-GCC 2" was worth doing. I'm not sure 99% ever even tried it. That was back starting in 2009. Obviously people these days are even less sympathetic towards floppies! That GCC is "too old" for most projects. Nobody wants vanilla standard minimal console stuff: they want GUIs, networking, threads, you know ... all the non-portable flashy stuff. I just figured easing deployment of a minimal DJGPP would make it easier to bring the toolset to old computers. (Unfortunately, a 486 is too slow for such a version, -O0 was 2x or 4x slower than 2.7.2.1 "-O2"! But at least you can fit all of it on a small RAM disk, which combined with a software cache will speed up compiles tremendously.)

> It really all started when somebody criticized me over my floppy drive.
>
> That was me, and the USB stick too. Both resulting from doubts about the
> core problem posed.

Why should your dislike of floppies have to carry over to me?

I have a whole bunch of usb sticks and I can access them from DOS just fine.
What do you want me to do with them.

As I said on FP all my OS and OS utilities are on a HD and they fit
on a floppy. My large apps are on a USB stick in ZIP files loaded to ramdisk
in a.bat.

>
> > And I was criticized over my preference of small programs.
> Selecting small is a waste of time they said.
>
> (it _is_ IMHO)
>

For example on my big USB where I store a lot of things I have 5 TEEs
ranging from 57kb to 5kb and I selected the 5kb for my OS utilities.

Why was this a waste of time in your opinion.

> None of these had anything to do with FP, but they became major components
> of the thread.

This remains true.

>
> It is in the sense that FP is a modern development system.
>
> Anywa, the answer to your question is simple:
>
> Use the oldest possible compiler, code your programs as
> low level as possible, and use a customized RTL that cuts
> away things you don't use. (and the older you go the less cutting you
> will do probably)

I have been using G77 for a long time.
I just wanted to ask about FP to see if it would be interesting to check
out and FB too. The answer is no. I can stay with G77.

Why was such a bit rucus necessary?

>
> For Turbo Pascal code that is probably TP55, BP7 whichever has the best
> ratio wrt code generation and customizable RTL.
>

I have been maintain DOS systems for people in my companies as far back
as 1985. One master floppy disk, format the users hard disk, SYS it, and
copy over all the files to the bootable HD. Boot and run.

> Maybe FPC 16-bit has long term better papers (it has potential for better
> optimization and since it is open source you could in theory beyond that),
> but that is not here and now, and the RTL customization will probably be
> more involved anyway (since it is more complicated)
>
> If I offended you I'm sorry, but please take the fact into
> consideration that I have answered such questions for 17 years now, and
> never saw a constructive outcome. People seem to be shopping around to
> keep their aging setup running for a while longer, but it isn't allowed
> to cost any effort. Basically it is compiler shopping.

MY bootable floppy, I have maintained it since 1985 and I upgrade it about
every 5 years.

Is this your opinion od all the people here on BTTR never constructive outcome.

Sorry but I have a fine DOS system, I use it when It is the way to go,
I run SPINRITE once in a while to refresh my disks and if and when WIN7
crashes I will use IMAGE FOR DOS from Tettabyte Unlimited to restore it.

SB

> > And I was criticized over my preference of small programs. Selecting
> small
> > is a waste of time they said.
>
> (it _is_ IMHO)

What email provider do you use? What is the file attachment limit? How much of that is eaten up by the MIME/base64 conversion?

What ISP do you use? What download/upload speeds do you have, and do you have any caps on total usage?

What motherboard do you use? How much total RAM can you install?

What OSes do you use? How much total RAM do they see? How much can an individual app appropriately utilize?

What file systems do you use? What is the maximum partition size and maximum file size? What cluster size is being used (slack space)?

Note that many Linux distros (et al.) have trouble cramming everything even on a CD, so some of them have switched to DVD. And of course DVD is too small for some things, hence dual-layer (or beyond) or Blu-Ray, etc. etc. So it's not like floppies are the only ones running out of space.

> Use the oldest possible compiler, code your programs as
> low level as possible, and use a customized RTL that cuts
> away things you don't use.
>
> For Turbo Pascal code that is probably TP55, BP7 whichever has the best
> ratio wrt code generation and customizable RTL.

TP55 is very small but also not very complicated. And obviously pure assembly is going to be smaller than almost anything.

> If I offended you I'm sorry, but please take the fact into
> consideration that I have answered such questions for 17 years now, and
> never saw a constructive outcome.

1997? You seriously want to pretend that you're using the same (or even similar) setups as back then?? Not even the same dialects or architectures! (TP only and no AMD64.) And size usually mattered more back then than now.

I'm not saying size is very important in most cases. Obviously people don't know, don't care, don't have time, "it just works", etc. But it's ridiculous to pretend that it's somehow bad to actually identify and fix the problem!
(But presumably you're just complaining about the complainers, not those actually doing work to fix this. Not that anybody is actually fixing anything here, sigh.)

> People seem to be shopping around to keep their aging setup running
> for a while longer, but it isn't allowed to cost any effort.
> Basically it is compiler shopping.

He mentioned G77 (presumably with DJGPP; and not Gfortran??), so no idea why he's looking at FBC and FPC. Obviously the point is that different languages aren't comparable. AFAIK, nobody chooses a compiler for size alone but instead for what language dialects and what target architectures (and target OSes) it supports. Size doesn't matter if you don't grok the compiler language!

But I don't think you were really advocating here that everyone should rewrite all their code every other year, just to follow latest trends. The idea that everything must be handled by the end user, no matter how complicated, and totally ignoring legacy concerns (which is all too common these days), is ridiculous. Obviously FPC isn't that stern (thankfully).

You'll have no such problem here on this board.

All of us are quite proud to still be using DOS and tiny 100% DOS programs.

Thank you thank you.

SB

ASIC BASIC for DOS could create a Hello World com in 360 bytes (according to Wikipedia)[1]. I think one could get that down to about 32 bytes if you only used ASM.

[1] http://en.wikipedia.org/wiki/ASIC_programming_language

> > > Last but not least, I assume LD got an update somewhere along the way.
> >
> > Nope, FPC 2.6.2 GO32V2 is still using old 2.17 from 2008,
>
> Laaca was comparing with FPC 1.0.10 which is from 2003.

1.0.10? Verboden!

I don't know if much has majorly changed since then (2.8??) and now (2.17). I honestly don't think it would make a difference at all!

I do know that Juan increased / fixed the max reloc limit circa 2.22-ish, and latest is 2.24r2. DJ is still COFF maintainer for us, but I don't know if he's done any "major" work on it in a billion years.

It seems that GNU (BinUtils, GCC) mostly only care for ELF with partial concern for other (tier two) platforms (Mac OS X: Mach-O, Windows: PE/COFF). DJGPP gets very little, if anything, from them. Even online LD changelog doesn't say "DJGPP" at all anywhere. Plus, MIPS ECOFF was removed in 2.24. (Similarly, GCC dropped "generic COFF" back in 4.5.x days, IIRC.)

BTW, I remember saying FPC didn't work with 2.19, but obviously nobody (nor I) ever fixed that nor delved deeper. So FPC may not work with newer ones. Ironically, I think the only impetus to upgrade BinUtils for DJGPP is probably the opposite: newer GCCs won't work with older ones.

> True, but since Go32v2 (and I assume DJGPP) programs are smaller, you can
> go the "generate one assembler file per symbol, and then AR them together"
> way.

I don't know if FPC GO32V1 is smaller output than FPC GO32V2.

DJGPP v1 was smaller than v2 because it had a separate GO32.EXE extender as well as lesser support (no LFNs, no symlinks, less POSIX, etc).

> FPC 1.x did that, and yes it is a bit slow, but not that bad on Go32v2.

Untested, but I still assume old FPC 1.x is faster just by virtue of doing less.

> FPC 1.9 and higher did the AS and AR step internally for (our) TIER 1 minus
> OS X.

What is FPC tier one? Linux + Windows on i386 or AMD64?

> Wrong. It happened because nobody created proper section smartlinking for
> those binary targets.

32-bit flat memory model (and virtual memory) implied that everything was practically "unlimited". So nobody cared about a few more megabytes. Besides, AFAIK, DJGPP was never commercially funded. It's always been very few volunteers. So the urge was even less, even back when Win9x was ubiquitous.

> A library programmer can't be required to assume responsibility for each
> and every dead or sleeping target because he wants to change a couple of
> lines. One might as well cease development of the library code.

First priority is just to get it working. But to imply that one isn't responsible for one's own code footprint is a bit naive. Just because nobody cares or takes initiative doesn't mean it's not worth doing.

> That being said we try to avoid making global decisions on FPC without
> testing them on both windows, OS X and Linux. This to avoid unixisms
> creeping in.
>
> Note that the internal linker should make it easier to create snapshots on
> non-dos, though probably still an AS is needed for the startup code. (but
> caching that near immutable file and replacing it with an dummy AS might
> work)

"Wanted: AS for bootup"

That's what the README says. I have not installed this package yet.
If I do have to reboot it's not a big deal.

SB