DOS ain't dead

FPC 2.2.2 rc1 is out, dos version inclusive at a meagre 48MB src inclusive, and 13MB without. Please give it a good spin and report your bugs in mantis, so that we get the dos port up to speed again!

Archive:
ftp://ftp.freepascal.org/pub/fpc/beta/2.2.2rc1/i386-go32v2/

Mantis:
http://bugs.freepascal.org/

URL to the release manifest
http://lists.freepascal.org/lists/fpc-devel/2008-June/013918.html

EDIT by rr: changed subject from "fpc 2.2.2 rc1"
EDIT by marcov added release manifest url.

I downloaded and briefly tested FPC 2.2.2 rc1 and the impresions are generaly positive.

+there are my fixes about mouse cursor included (although some minor problems with alternative VESA capable video driver used in IDE remain)
+now can properly compile even without DOSLFN installed. (prior versions reported "Can not find unit system)
+compiles all sources I tested without any problems
+compilation seems to be somewhat faster than in 2.2.0a

-no debugger support in distributed IDE. (however you can get it by recompilation the IDE sources)
-generated EXEs are much bigger than in 2.2.0a without obvious reason
(-) not a bugs but missing features:
color selecting dialog still not available
topic help in IDE by pressing CTRL-RMouse still opens only help index but not the topic like Turbo pascal does.

---
DOS-u-akbar!

> I downloaded and briefly tested



> + can properly compile even without DOSLFN installed.

Also itself ?

> - generated EXEs are much bigger than in 2.2.0a without obvious reason

Yeah

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

> -no debugger support in distributed IDE. (however you can get it by
> recompilation the IDE sources)

I will relay that.

> -generated EXEs are much bigger than in 2.2.0a without obvious reason
> (-) not a bugs but missing features:

Do you have a feeling what it can be? Specially the "much" bothers me, maybe smartlinking disabled for packaged units or so? Do you have -XXs or so in your fpc.cfg ?

> -generated EXEs are much bigger than in 2.2.0a without obvious reason
> (-) not a bugs but missing features:

It seems that smartlinking is totally disabled. There are no .a files in the release.

It could be that they have a newer linker (removing the need for .a's and making the distro significantly smaller) and try section smartlinking, but that that isn't working properly or so.

I'm discussing it on fpc-devel (where I posted your comments), and added the findings above to your bugreport

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

---
DOS-u-akbar!

I have few questions about position independent code.
1) what is it?
2) what is it good for?
3) has it got any meaning for DOS?
4) how can I use assembler with it?
(it gives an error in assignments like MOV GLOBAL_VARIABLE,1)

---
DOS-u-akbar!

> I have few questions about position independent code.

ANSWER (general, not FP-related)

> 1) what is it?

Code than can run at any address, needs neither to:

- sit at ZERO or fixed address in a private segment like DOS COM 16-bit RM (0) or DGJPP / FPC-GO32 (0) or Win32-PE-EXE ($400000)
nor
- use silly fixups (partially MZ DOS EXE, WATCOM/LE, PE-DLL)

> 2) what is it good for?

Avoiding segmentation and fixups, using shared libs / objects / drivers ( YES - DOS needs reusable 32-bit PIC drivers )

> 3) has it got any meaning for DOS?

YES, see above.

> 4) how can I use assembler with it?

Reserve one register ( EBX ? or FP will decide for you ?) for global base, and index all global vars with it.

          call  varbase ; & MOVNTQ EBX,EIP
varbase:  pope  ebx     ; &

;         inc   byte [blah]
          inc   byte [blah-varbase+ebx]

> (it gives an error in assignments like MOV GLOBAL_VARIABLE,1)

Because absolute addrs are prohibited, see above.

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

> > 2) what is it good for?
>
> Avoiding segmentation and fixups, using shared libs / objects / drivers (
> YES - DOS needs reusable 32-bit PIC drivers )

For what? IMO absolutely useless for DOS.

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

---
MS-DOS forever!

> > 2) what is it good for?
>
> Avoiding segmentation and fixups, using shared libs / objects / drivers (
> YES - DOS needs reusable 32-bit PIC drivers )

Sure, but fixups work too, and are way cheaper (PIC bloats and slows code significantly on x86) However the main reason is to be able to multiple load dynamic objects at different addresses, and still share them.

PIC and assembler is complicated, since accessing all global symbols gets more complicated.

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

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

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

I don't know if this is similar enough but NASM supports using AMD64/x86_64 RIP-relative addressing in 64-bit mode. Though 32-bit mode would have to use another base address register it seems to me the support is already there; or at least the most work for it. However I don't know how the RIP-relative addressing works so this might be wrong.

---
l

> > 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.
>
> I don't know if this is similar enough but NASM supports using
> AMD64/x86_64 RIP-relative addressing in 64-bit mode. Though 32-bit mode
> would have to use another base address register it seems to me the support
> is already there; or at least the most work for it. However I don't know
> how the RIP-relative addressing works so this might be wrong.

Yes, that is it. But that is a normal feature for any x86_64 tool, since the instruction set defines it.

Probably what is meant that NASM allows defining symbols that are relative to RIP too, and when assembling the offsets get corrected as they should.

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

> > No PIC
>
> What is this ? A guess ? A theorem ? A prohibition ?

it's a negation.

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

Why not? Sometimes examples are made to show how things should not be. AFAIK you're familiar with the FASM forum, so just look into the Linux subforum and see the confusion about how shared objects are to be created with Fasm/assembly ... then it might become obvious to you that calling it CRAP is indeed an euphemism.

> I'm confused

This was my intention.

---
MS-DOS forever!