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

[PascalDragon]

By looking how microsoft has designed it to be.

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

1. function WriteFile(hFile: THandle; const Buffer; nNumberOfBytesToWrite: DWORD; var lpNumberOfBytesWritten: DWORD; lpOverlapped: POverlapped): BOOL; stdcall; external 'kernel32.dll' name 'WriteFile';
2.  

And the definition of WriteFile you showed violates the advice you gave.

WriteFile's Buffer parameter should NOT be untyped.  That is incorrect.

If it works correctly when called accordingly (namely by not passing a pointer or by dereferencing it) it does not make it incorrect. It is simply not equivalent to how it's declared in MSDN.

Also, the lpNumberOfBytesWritten should NOT be a "var" parameter because, except in Windows 7, that parameter is optional, therefore it should be typed as a _pointer_ to DWORD.

If one knows how, one can still treat it as optional:

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

1. WriteFile(h, buf, SizeOf(buf), DWord(Nil^), Nil);

[TRon]

in general, you would not making a question on a question.
That is not gentle.

It is the same gentleness you provided the reader with omission of details. And the question itself was a hint.

Please enlighten me how I should answer your questions so that they meet your expectations and standards.

I can not ask your question's, because I don't know that FPC needs so many compilerproc functions, and procedures.
As such, I would be expect, that FPC sould me let to make/compile my own stuff.
As such, I would be expect, that you can help me with working things.

For me, I can not claim, that you give anything.
But I would expect solutions (so little they are) - and not the things like: "use existing code.".

I rest my case. I got better things to do with my time than copy-pasting existing implementations.

edit: you seem to misunderstand that writing your custom RTL means that you are the one that set the rules not us the reader but you keep failing to inform. To me it looks like you are just YOLO-ing things and expect answers when you got yourself into trouble.

[paule32]

@PascalDragon:

you made my day !
Thank you.

[440bx]

If it works correctly when called accordingly (namely by not passing a pointer or by dereferencing it) it does not make it incorrect. It is simply not equivalent to how it's declared in MSDN.

I'm afraid I have to disagree.  It is incorrect.  One of the reasons (yes, there is more than one) it is incorrect is because there is no documentation of FPC's "flavor" (that's the diplomatic word, the accurate word is _wrong_) of WriteFile.  This means that when a Pascal programmer looks up how to call WriteFile, that user is going to find (apparently, "surprisingly" to some Pascal programmers) the MSDN definition and its documentation.  After the unsuspecting soul codes the call to WriteFile as specified by MS, a "miracle" happens: it doesn't work BUT, some Pascal programmers here (you among them) say the FPC WriteFile definition isn't wrong, the guy just didn't read the right (likely non-existent) FPC WriteFile documentation.

There is one thing I must agree with you: the definition is not "equivalent", definitely not.  We are in complete agreement.

If one knows how, one can still treat it as optional:

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

1. WriteFile(h, buf, SizeOf(buf), DWord(Nil^), Nil);

Of course, why do it right when it can be done wrong and work around the wrong definition by using a rather questionable trick.  The whole purpose of "var" is to specify that a _reference_ is required.

[paule32]

@TRron:

now, I can give you more details...
In the documentation of the FPC command compiler options, there is a paragraph:
https://www.freepascal.org/docs-html/user/userap1.html

  -C<x>  Code generation options: 
      -C3        Turn on ieee error checking for constants 
      -Ca<x>     Select ABI; see fpc -i or fpc -ia for possible values 
      -Cb        Generate code for a big-endian variant of the target architecture 
      -Cc<x>     Set default calling convention to <x> 
      -CD        Create also dynamic library (not supported)    <---- there

The idea I have is, that I use an application as server application (the DLL), and provide a SIGNAL like concept, to interact with the DLL and the EXE.
This means under Windows: you easily use SendMessage to a Handle that is stored as text into the external WriteFile file.
The value string in this file, will be converted back to integer/hexa decimal to get the handle.

depend on this, I could output some other code and data informations,
that can be used for FPC and/or GCC.

[paule32]

@440bx
@all

you can take a look to my fresh updated github.com sources:
https://github.com/paule32/Qt_FPC/

WriteFile works like a charm.

A working (testing) DLL + EXE can be found there:
https://github.com/paule32/Qt_FPC/releases/tag/tag3

[KodeZwerg]

@440bx, okay since you are not stopping to blame my code, you have my full working testcode, make it crash boom bang, can you?
If you managed to make it crash, show what you modified that it can crash.

[paule32]

UPDATE 

since the DLL work, I found a very nice tool called objcopy.
With this tool, you can re-define the symbols of an .o bject file.

On my test's, this shrinks my FPC_RTL.DLL from 11.000 Bytes to 9.000 Bytes.
The TEST1.EXE is in size by 6.500 Bytes.

I saved 2.000 Bytes on the DLL.
When I run upx.exe over the EXE, I end up with a 4.096 Byte sized EXE binary image.

So, I end up with this on with  16.500 Bytes (6.400 Bytes zipped file) for the DLL + EXE.
Or: 13.000 Bytes in total (with upx.exe).

Please, don't bite me - the file size values there are rounded, because I am to lazy to calculate the differnt differences 

[440bx]

@440bx, okay since you are not stopping to blame my code, you have my full working testcode, make it crash boom bang, can you?
If you managed to make it crash, show what you modified that it can crash.

You're missing the whole point.  That definition of WriteFile is wrong and, as I stated in a previous post, the fact that it can be made to work does _not_ change that.  It is still wrong.

I and, just about anyone, can make that incorrect definition work too, as a matter of fact, I have throw away code (that I haven't thrown away yet) that uses it.   (guess how I noticed the definition is wrong)

What neither you nor anyone can do, is code a call to WriteFile that complies with MS' spec (the author of the function) using the Pascal definition and make it work.  No one can.  The reason: because the Pascal definition is _wrong_.

Lastly, it isn't about your code, it is about the Pascal definition being wrong/incorect.  That's what it's about.

Programming seems to be the premier activity where errors are worshiped and perpetuated.  We "cannot correct that" (whatever "that" may be) because it would break a lot of wrong code we have and we don't want to correct the code (too much work), if we did, we'd have to test again and we'd run the risk of missing a side effect brought about by the correction.  Can't have that.  Instead, we'll claim it's not wrong, just not "equivalent".

However, in spite of the definition because wrong/incorrect, all those who pretend it is not, are _absolutely right_.

I'm going to call that "binary diplomacy". 

[KodeZwerg]

You're missing the whole point.

After reading I do agree you.

[paule32]

it is a little bit hard to follow the postings from 440bx.
Is the point the "definition" ?

[TRon]

Is the point the "definition" ?

Yes.

And as a consequence how your code calls that routine (e.g. what parameters (types) you pass it).

[paule32]

Hello,
it is possible to change the creation of Assembly by FPC through some parameters or options ?

I have the following code:

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

1. s1 := QString.Create;

which results into assembly code:

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

1. mov     ebx,edx
2. mov     edx,1
3. lea     rcx,[VMT_$SYSTEM_$$_QSTRING]
4. call    SYSTEM$_$QSTRING_$__$$_CREATE$$QSTRING

my intention is, to get the replacement of it like:

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

1. mov     ebx,edx
2. mov     edx,0
3. lea     rcx,[VMT_$SYSTEM_$$_QSTRING]
4. call    SYSTEM$_$QSTRING_$__$$_CREATE$$QSTRING

How can I do this ?

I know, that there are the keywords asm ... end;
But I would let FPC do this for me from pascal code.

[Thaddy]

You should not mess with the create. So, no. 1 is an index....
What do you want to achieve?
The lea would probably crash big time.

[paule32]

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