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

[rvk]

a index, to the VMT table of QString ?
how about this table ?
is it (the strcture) documented ?

I mean, I see the TVmt record, where the first Index point to: vinstanceSize: LongDWORD

You still don't mention what you want to achieve.
Why do you want to change that code?

Of you want to do that, you'll probably need to change the fpc source itself.

[paule32]

@rvk:

DONT CHANGE A RUNNING SYSTEM - TRUST YOUR OWN BILL'S

UPDATE:   
https://github.com/paule32/Qt_FPC/releases/tag/tag3

The goal is it, to use FPC with minimal binary code usage.
You have some option's under Microsoft Windows 11 64-Bit Professional.

And the second goal is it, to advertisement Windows 11 as a good Operating System.
Don't blame on it - Windows grow, don't shame you to use it !!!

I would not flame war or face palm something.
But, I have the opinion, that each of us should us their favorite System of his/him/her needs fit.
Not lesser, not more.

[rvk]

[...]

I meant, why do you want to change that edx to 0 instead of 1 ?

Or was that just a random (nonsense) example?
( you might have mentioned that that was just a hypothetical example)

If so, do you have actual asm improvement you want to suggest?

(The mailinglist might be a better place to suggest those changes because I think the majority of the core developers hang out there.)

[paule32]

I had a chat session with Jester on Liberia.com at the assembly channel.
Because I asking, why the application I currently programming on crash in the runtime.
As such, we discuss, what assembly is used, and why.

Then, today's night, I had a talk with ChatGPT, and I was surprising which results came out to understand the assembly better and better on a advance user point of view. I have to say, that I am not the assembly guru. But ChatGPT was my miracle on this.

As such, I used the SED - the Unix Stream EDitor tool, to patch the assembly sources that was produced by the FPC Compiler.
So, could filter the sources, and adding patched Code.

As example, I add pascal code in Delphi classic way for class usage like:

Code: Pascal  [Select][+][-]

1. type
2.   TMyClass = class
3.   public
4.     constructor Create;
5.   end;

This produce me a very lot of assembly code with the symbol name:
SYSTEM$_$TMYCLASS_$__$$_CREATE$$TMYCLASS

Don't make thinking's on what this is - it is the mangled name when you use:
foo := TMyClass.Create;

I could shrink the code to a minimum of:

Code: ASM  [Select][+][-]

1. section .text
2.  
3. global SYSTEM$_$QSTRING_$__$$_CREATE$$QSTRING
4. SYSTEM$_$QSTRING_$__$$_CREATE$$QSTRING:
5.     push    rbp             ; save current stack value
6.     mov     rbp, rsp        ; update rbp to show to new function body
7.     sub     rsp, 8 * 3      ; reserve 24 (8 * 3) Bytes
8.    
9.     add     rsp, 24         ; reset the stack
10.     mov     rsp, rbp        ; set rsp value to rbp to reset stack
11.     pop     rbp             ; get the last value of rbp
12.     ret                     ; return to caller

But this was not enough for me - because each class member including ctor and dtor, you have so very long symbol names in the finally binary file, that you could think, that 50 percent of the code is text of symbol names, that you never ever need.

So, I did a little research.
And as a lazy programmer I found a solution.
It is called objcopy - a tool, which can help to re-define the symbols of object files.

This means, you can make the symbol name "foo" from the existing symbol name "abracadabera_along_long_name".
You can see the differences ?

Okay, I did a little more research, and sed-out more things like RTTI - the Run Time Type Informations.
Because not every programmer or end user of the application need such huge informations about the internal structure of the application.
Okay, you can say they are important for debugging and problem sending from the user.
But in my case, I don't need RTTI at this time, so I skipped all information's data from the assembly data - which takes in effect to a smaller finally out, again.

The total sum of steps, to reproduce this, what I doing there would be over-helm the one or the other, so I don't going into the details of all of it. You only need to be a little bit advance programmer/developer to understand the build batch file that I ship with the source project files that I hosted on github.com.

If you have any question's about this script, you can drop a message and I would try to clarify your concern's or service request's.
But don't except that I have a recipe for all 

All of this means of procedural/functional programming and not object orient programming.
But thinking in assembly: All are linear data containing 0 or 1 on the very lower level.

I could say: Stay tuned 

[paule32]

when I try to concatenate a PChar with String:

Code: Pascal  [Select][+][-]

1. foo := 'text';  // this will work
2. foo := 'text' + pchartextvar;  // this will not work.

The signature of the function is:
function  fpc_pchar_to_ansistr(const p : PAnsiChar): AnsiString; compilerproc; overload;
function  fpc_pchar_to_ansistr(const p : PChar): AnsiString; compilerproc; overload;

and the Error output on the console is:

Code: Bash  [Select][+][-]

1. Error: Wrong number of parameters specified for call to "$fpc_pchar_to_ansistr"
2. Error: Found declaration: $fpc_pchar_to_ansistr(const PAnsiChar):AnsiString;
3. Error: Found declaration: $fpc_pchar_to_ansistr(const PChar):AnsiString;

so, what parameter is missing ?

UPDATE:
I tried to use operater overloading on using objfpc mode with advanced records option...
When I use this code (operator):
operator + (const Value1: PChar; const Value2: PChar): PChar;

I get:
Error: Impossible operator overload

So, what do i missing ?

[rvk]

But this was not enough for me - because each class member including ctor and dtor, you have so very long symbol names in the finally binary file, that you could think, that 50 percent of the code is text of symbol names, that you never ever need.

Do those symbol names really end up in your binary?
Even if you compile without rtti and debug info?

It shouldn't.
An assembler symbol should just be a pointer to a memory address and in the end the symbol itself shouldn't end up in the binary. Or am I missing something?

[KodeZwerg]

Do those symbol names really end up in your binary?
Even if you compile without rtti and debug info?

It shouldn't.

And they dont else reverse engineering would be drastic become easy for everyone and not just the experts.
That would be a reversers dream to know all the time the meanings of everything without the need to actual watch asm code at given adress.

An assembler symbol should just be a pointer to a memory address and in the end the symbol itself shouldn't end up in the binary. Or am I missing something?

You did miss nothing, within binary are just offsets stored (the "pointer") that hold the location of the snippet its linked with (the "memory adress").
But above might only be true if next statement is real or wrong:
Does paule32s tinkered custom compiler/linker does do it similar = IDK.

[paule32]

Hello, and good morning,
if you take a look to the build.bar, you can see at lines: 292, and up, the following texts.
In general, I look to global symbols that are flagged with T, and to import symbols, that
are flagged with I.
Then, I re-define it with a shorten hex-number - nothing else.
I think, this is the way, Microsoft hide it's super dubba secret code in the DLLs to call to home ...

Code: Bash  [Select][+][-]

1. :: -----------------------------------------------------------------
2. :: collect file informations fron the import archive .o files ...
3. :: -----------------------------------------------------------------
4. nm *.o | grep ".* T .*" | awk '{print $3}' > import.tx2
5. for /f "usebackq delims=" %%A in (import.tx2) do (
6.     set "string2=!counter!"
7.     printf "%%A \\x!string1!\\x!string2!\n" >> import_funcs.map
8.     set /a counter+=1
9. )
10. :: -----------------------------------------------------------------
11. :: patch the de-packed object files ...
12. :: -----------------------------------------------------------------
13. dir /b *.o > importFileList.txt
14. for /f "tokens=*" %%i in (importFileList.txt) do (
15.     objcopy --redefine-syms=import_funcs.map %%i )
16.  
17. :: -----------------------------------------------------------------
18. :: patch the project library files import data ...
19. :: -----------------------------------------------------------------
20. for %%B in (%prjdir%\units\fpc-rtl\system.o %prjdir%\units\fpc-rtl\fpc_rtl.o) do (
21.     objcopy --redefine-syms=import_funcs.map %%B
22. )
23.  
24. echo =[ patching lib imports... ]=
25. nm *.o | grep ".* I .*" | awk '{print $3}' > import.tx2
26. for /f "usebackq delims=" %%A in (import.tx2) do (
27.     set "string2=!counter!"
28.     printf "%%A \\x!string1!\\x!string2!\n" >> import_funcs.map
29.     set /a counter+=1
30. )
31. dir /b *.o > importFileList.txt
32. for /f "tokens=*" %%i in (importFileList.txt) do (
33.     objcopy --redefine-syms=import_funcs.map %%i )
34. for %%B in (%prjdir%\units\fpc-rtl\system.o %prjdir%\units\fpc-rtl\fpc_rtl.o) do (
35.     objcopy --redefine-syms=import_funcs.map %%B
36. )

I always was too lazy again, to collect and tackle flagged symbols that are flagged with U.
So, I have the following lines at 348 (before, and after) in the build.bat file, so
these lines look upon these symbols, and let them untouched in the binary image:

Code: Bash  [Select][+][-]

1.     nm %prjdir%\units\fpc-rtl\%%B > %prjdir%\units\func.tx1
2.     grep ".* T .*" %prjdir%\units\func.tx1 | awk '{print $3}' >  %prjdir%\units\func.tx2
3.  
4.     for /f "usebackq delims=" %%A in ("%prjdir%\units\func.tx2") do (
5.         set "string2=!counter!"
6.         set flagged="F"
7.         if "%%A"=="VMT_$SYSTEM_$$_QSTRING"          ( set flagged="T" )
8.         if "%%A"=="FPC_EMPTYCHAR"                   ( set flagged="T" )
9.         if "%%A"=="fpc_libinitializeunits"          ( set flagged="T" )
10.         if "%%A"=="fpc_ansistr_decr_ref"            ( set flagged="T" )
11.         if "%%A"=="_DLLMainCRTStartup"              ( set flagged="T" )

Take noted, that this lines and codes represents the current status at 2024-04-22 05:30 !

In the attachment, you can see the references as hex symbols - and the above
described untouched symbol names.

[rvk]

In general, I look to global symbols that are flagged with T, and to import symbols, that
are flagged with I.
Then, I re-define it with a shorten hex-number - nothing else.
I think, this is the way, Microsoft hide it's super dubba secret code in the DLLs to call to home ...

Have you looked at the options --strip-debug, --strip-symbol or -x or any other options to strip the symbols from the.dll and .exe ???

Or have you even asked anyone if this is possible ???
Instead of trying to do things the hard way.

Several utils have the option to strip those symbol tables. It's not needed to do this before compiling in the source. It will save you even more space because it will get rid of the complete symbol table. Even the one with the mangled/obscured hex symbol names you have now.

[paule32]

I know about the strip tool - I used at end of all linking.
Bevause, it strip all debug information's but not the GOT - Global Offset Table where each symbol name get it's address of in the .SO or .DLL file.
The implementation is operating system depend - but works on all with the same behavior.
It makes the developer easier to handle it with linking.

My intention was not to make it harder - it was, to minimize the end-user binary image.
The end-user don't need those information's - you can always pop out debug messages independent from the based information's.
So, you can "ShowMessage('FTHW is this?');" if you open a file. For this, I don't need RTTI.

[paule32]

UPDATE 

I came to the conclusion. that FPC really don't support DLL import's at current time.
Using C/C++ DLL files are much cleaner.
But I stay tuned on the project...

It is very interesting what you can simply do with Pascal.
There is a payload, okay.
But you can profit of them in later use.

[Thaddy]

What??? I give up on answering you.

[paule32]

@Thaddy:
this does NOT depend on the original FPC, and RTL !!!   

[rvk]

So, you came to the conclusion that FPC your RTL really doesn't support DLL import's at current time 

That's something completely different 

[paule32]

@rvk:
nono, ...
I can import C functions from external DLL files.
I can NOT import PAS functions from FPC created DLL files.

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

As such, I completely remove RTTI, and Debug stuff using the SED tool.
Did you don't look to the build.bat ?