DOS ain't dead

> Yes, you are right!
> In FPC 2.2.2 the smartlinking is completely disabled. There are no .a
> files in .\units subdirectory nor any other .a files can be created. If
> you compile the same source with and without smartlinking the binary is
> exactly the same - in short, this option has currently no effect at all
>
>
> BTW: I compared the EXE size of Blocek 1.33 by different compilers (with
> same settings):
> FPC 2.2.2 with or without smartlinking: 556544
> FPC 2.2.0 without SL: 494080
> FPC 2.2.0 with SL: 413184
> FPC 1.0.10 (no SL option): 387072

I see that Giulo is committing Dos fixes at an ever increasing speed, so rc2 will be better. Including this smartlinking problem and the installer diskspace problem under NT based windowses.

I'll monitor SVN a bit, to be sure they are merged in time, but by the looks of it, Giulo can merge himself just fine, so it probably will be ok.

> > Reserve one register ( EBX ? or FP will decide for you ?) for global
> base,
> > and index all global vars with it.
>
> Yes, but that's bullshit. PIC might be somewhat useful for Unix, for DOS
> and Windows it's useless, for ASM it's big CRAP.

It's not related to assembler or windows. It has to do with sharing of code in protected mode systems and dates from before C even existed.

Windows has less need for it, since it tries to avoid to reallocate as much as possible (in a static way), by fixing loading addresses, thus making the gains low. But it dumps the load on the programmer/user to avoid worst case scenario's. (make sure that all often used libs have unique addresses)

This is a reason why most newer systems try to make this more dynamic, there are roughly two skools of thought:
- Do the same as windows, but instead of having the programmer hardcode, maintain your own addresses, and cache a system of prerelocated libs. This maximise code execution speed.
- Use PIC and sacrifice code execution speed in favour of simplified loading.

Note that the choice of GNU for PIC was heavily influenced by their then main architecture (m68k) have far lower penalties on PIC as the x86 has. Most RISC archs also allow to explicitely load the program counter into a register, so x86 is alone in this (even more since the x86_64 arch also has this ability)

Another reason is the emergence of C++ code (and in general libraries in languages more advanced than C), that often export mountains of symbols that significantly delay program execution when loaded. (one of the reasons KDE, which is C++ implemented a preloading scheme after dog slow early KDE3 releases)

While PIC can complicate assembler significantly (global symbol access as Laaca already suggests), this maybe could be helped with some macro's or explicit in-assembler support. FPC doesn't do this yet afaik, search the FPC code (e.g. the rtl/i386/ dir) how to deal with it

People interested might look at the pic paragraphs in
http://norfs.sourceforge.net/linkers_and_loaders.pdf

which is in generaly a good ebook to keep on store if you have regularly business with linkers (I bought a hardcopy)

> No PIC

What is this ? A guess ? A theorem ? A prohibition ?

> Yes, but that's bullshit.
> for ASM it's big CRAP.

Thanks for letting me know. Surprisingly, you added a PIC example into JWASM at surprisingly same time as writing this post. I'm confused

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