How to: create DLL file for Windows 10 64-Bit Pro

[rvk]

But I think, this is a thing that the TVmt struct grounded.
Because I write earlier: I use my own RTL.

So with the standard RTL it works correctly...
and you blame FPC that it doesn't work with your custom RTL

[paule32]

I will revert the misunderstanding comment, and I will apologies me.
I was on first step with study the internals of FPC.
I was new to 64-Bit Microsoft Windows programming in assembly.

This depends in different ABI call's and API function's for
the different kind of CPU's and Operating System.

[KodeZwerg]

[sarcasm]

...blame FPC that it doesn't work...

dont we all do this from time to time when something seems to be unlogic and work not as excepted, ofc its fpc's fault since I am purrfect 
[/sarcasm]

Anyway, congratulations paule32 to find out that your way is a dead end 
At least you learned something about binary executable file structures even when I think it's from time to time misunderstood, wrong interpreted or wrong expressed.

As mentioned very early by me, if filesize is your only concern, Pascal is the wrong horse to ride with.

[paule32]

Hello,

As mentioned very early by me, if file size is your only concern, Pascal is the wrong horse to ride with.

That is my problem, and concerns - the size of the code.
Nobody make itself headache about, how application's can run faster, and consume lesser memory, and space on storage devices.
All of all would always more and more - more bigger, to better.

I came from the MS-DOS time (okay, I am over 40 years old, now. But I came in contact with computer very early - thanks to my parents, and teachers, and friends aka copy and play pirated Amiga 500 games *prrr... :-) )
So, in this time, each byte and bit was counted.

And the slogan was from a very important person:
2.048 MegaBytes (2 MB) was enough - you know the story ? 

And as such, I was growing with this slogan.
Because a night of a file full with PSET commands, after this frustrating moment as I came to the 64k limit ...
This tend me to use Turbo Pascal overlays ...

And the story begun ...
C/C++ EMS Windows 3.11 32-Bit programming with a DPMI proxy application make me lazy.

Years ago after this, I end-up with the same problem again.
The data information's goes bigger, and bigger - all of us know the BORLAND Delphi, and C++Builder ...
where no one was splitting data from the binary executable...

This concept came later: with HTML and CSS.
Before, all data was compiled into EXE - which makes resource memory leaks very sneaky.

Nobody have to know why I do this all.
Nobody have to use the software that I provide.

But I hope that all of them can be informal, and useful.
This is my vision: Provide Informal, and useful services.

[paule32]

UPDATE:   

I have started the Observer / Aspect programming interessts.
Now, the code base consists of pascal and c/c++ code.

[TRon]

...
I came from the MS-DOS time (okay, I am over 40 years old, now. But I came in contact with computer very early - thanks to my parents, and teachers, and friends aka copy and play pirated Amiga 500 games *prrr... :-) )
So, in this time, each byte and bit was counted.

And the slogan was from a very important person:
2.048 MegaBytes (2 MB) was enough - you know the story ? 
...

Then I must be older because I remember this quote 

Yeah the bloat sucks even if there is hardly any penalty these days (memory and storage are cheap) and some techniques used to prevent that bloat are going to waste and rot...

[paule32]

so far I know, Turbo Pascal under MS-DOS had Overlay files - a prototype of the next DLL step.
DLL was very helpful invention.
But all these "not" supported VScrt.dll's makes me "not" happy.

[marcov]

so far I know, Turbo Pascal under MS-DOS had Overlay files - a prototype of the next DLL step.

I programmed with overlays in (16-bit) Topspeed line of compilers and also a bit in Turbo Pascal.  Overlays were a necessary evil due to memory limitations, but had many problems.

E.g. in general you still had to upfront to reserve memory for the largest combination of overlays, so you still lost the memory (no virtual memory, reserving means losing memory). Also the overload usage itself had some overhead (e.g. no dead code elimination)

Basically, the only use is that if you had vastly different modes for the application that are mutually exclusive you could gain some memory.  E.g. a setup application vs an (textfile) editor.

But in practice from 1992 onwards with multitaskers/OSes like  Desqview , OS/2 and Win 3.x (and later win9x) allowing multiple dosboxes, it would be better to simply split them into two different programs, and have the setup (or nodelist processor) application write a semaphore to signal the main app to reread its configuration.

I didn't use overlays in 16-bit extender mode (I only used that for a very short time), maybe that was better.

[paule32]

simply split them into two different programs,

would you split FPC ?
I think, not all of us use the same mode (Delphi/Mac/...)

Maybe FPC is faster when this bucket of code support is outsource to different kind of software ?
Okay, more to maintain...

But this can help to decrease the size amount of FPC.
Maybe little more modernize the code base ?

This are all mind thinking's ... not a have to do !

[marcov]

simply split them into two different programs,

would you split FPC ?

Back then, maybe yes. The classic  make-compiler-assembler-linker is exactly done for that reason, to maximize the amount of memory that can be used to process each step. But when I started with FPC, memory sizes already were like 64MB I think.

Nowadays I wouldn't consider such options, since the division makes the result slower, which is nowadays FPC has internal assemblers and linkers (and the EXE is still only 3MB)

I think, not all of us use the same mode (Delphi/Mac/...)

I'm also no longer limited to effectively about 600 kb memory on PC.  So I wouldn't bother with code memory optimisation unless it really is a problem. 

Embedded is slightly different, but as the I/O boards are mostly for real time signalling, the problem set is also different (and proportionally smaller). My largest program is 28kb or so and contains a 9kb UDP socket stack and 3 motor drivers.

Data memory is mostly static and 3kb normal data segment and maybe another 4kb of buffers for the UDP socket stack
 

Maybe FPC is faster when this bucket of code support is outsource to different kind of software ?

Fragmenting is always slower. Some symbols need to be an extra indirection to be properly re-locatable etc etc. You add complexity with additional memory limitations, and any extra limitations nearly always cost speed, since memory constraints leading to swapping to disk is rare nowadays.

You can find 8GB RAM computers in dumpsters nowadays.

[paule32]

You can find 8GB RAM computers in dumpsters nowadays.

NA.
My discussion would point to retro-programming, and android.
You have already for all platform a version of FPC:
- for Amiga
- for MS-DOS
- for Windows 3.1
- for GameBoy
- for Android
- for ARM
...
All this different platforms comes with different logic - in programming, and in view of hardware.
That would be the point of me.

Me, as developer, I am toooo lazy.
So the actual QT_FPC project was born in the hope, that I am (and others) can use Qt5 wiith using real OOP techniques like using class's instead of procedural, functional programming with object's.

You must not know or understanding my waste of time.
You could see it in me as a hobby, to test the borders of the possibilities of modern software and tools in the open source corner.

If the results finally really help someone others, then it is a good invested time...
I have many time as freak there...
Many said to me, I am ill...
but: that's me :-)

[marcov]

My discussion would point to retro-programming, and android.
You have already for all platform a version of FPC:
- for Amiga
- for MS-DOS
- for Windows 3.1
- for GameBoy

Amiga's range from low to high (the later 68040 and PPC Amiga's are comparable to say pentium or the lower frequency Pentium-II PCs )

- for Android

Roughly same as PC. telephones have 4-6GB nowadays.

- for ARM

Too generic. It is like saying all x86 derivatives from the newest x64 to the 8088.

All this different platforms comes with different logic - in programming, and in view of hardware.
That would be the point of me.

Yes, but they are all different amongst each other too.  There are very few generalizations that apply to all of them. Anyway, we were talking about overlays, and that applies only to the sub MB or maybe a few MBs max. 

[paule32]

I don't believe, that I can programming real MS-DOS applications anymore.
Because - dosbox.exe can tweak the memory to over 16 MB.
My last 386 16 MHz PC that could be drop down to 8 MHz by pressing the Turbo-Key had only 2 MB of RAM.
Could not be know, how Windows 3.1 was running on ... :-)

[Mr.Madguy]

"ASM code is the smallest and fastest" - is the biggest programmers' misconception. Yeah, ASM code can be small and fast, but ASM programming means big overhead due to things like register allocation and low level optimization. Compiler can do such things better. And only way to achieve smallest code - not to use RTL at all. I've picked C++ to write my DOS projects exactly because it's very easy to do it there. It's as easy, as adding -nostdlib to command line.

[paule32]

I use gcc -nostdlib, too.

But the fact is, that the personal talented people will be smaller and smaller.
This is a generation value level where talents missing that can write Compilers.
It is not easy to write such kind of Software.
And software does not end up 100 percent - it will fast going on on the computer market.
I can honor such peoples that hold on the line in the Compiler workplace on open source
in a time, where donation work will not honor - my respect on this.

See the aspect: for few years ago, the Hubble telescope had a black out and run into the backup system.
Nobody was thinking, that the Hubble telescope could be repair - because no one of the programmers for the Hubble mission at the NASA control center was available.
So, the NASA was up-life a renew crew of old veterans, that could programming with the processors that was assembled in the Hubble telescope.
Firstly, they had to programming a kind of virtual machine in which the command sequences was tested before the new productive system was uploaded on the Hubble telescope.
The reason was simply:
They had problems with restore the backup system.
And they had only one changes - either the new productive was clean of bugs, and could be upload over the old system - or the mission felt into the water and was dropped (because the mission die - a financial disaster).
But, since the new webster Mission was lunch successfully, the Hubble telescope was no longer need for mainstream - and is satalite in the darkness of the universe.