Number 3.2 is not dead - it can look into the future !!! - or is it Voodoo ?

[rvk]

Why did I ask it there ?
Now, lets show the MessageBox - it will be displayed on Desktop (0 - Handle).
but, before you start the Application, the Second Line will cause a ill formed Action, so Windows print out the 0xc00005 Error.

Got the code to 'work' with FPC 3.2.0 (which is a very old version).

But... why do you think it has something to do with the move() or MessageBox itself???

I still think you have problems loading the dll itself (fpc_rtl.dll in this case).

And if you use move() in your code, the program NEEDS to load the dll before executing any code.
That loading process seems to throw the 0x000005 (AV) error.

Even move(p1,p2,0) will fail because it's just the loading of the dll that's failing here.
Commenting out move will just eliminate the need for the dll and the program runs correctly.

[paule32]

you are right.
But I have already working out the process of creating custom system.pas and compile it.
The PE image headers will be read-up correctly, and I don't get no error or AV if "move" line is comment.

My goal was, to test creating a custom .dll, and the .exe, to minimize binary data.

[rvk]

So, you understand now what the problem is
and why the code from your opening post behaved like that
and it's not voodoo or looking into the future at all.

[Thaddy]

You should not have move in a dll anyway, you should have implemented it in your system. That is not difficult.

[rvk]

The PE image headers will be read-up correctly, and I don't get no error or AV if "move" line is comment.

Have you tried adding something simple to the library fpc_rtl (just a simple procedure foo where you assign a variable).
And add the call to your test1.pas.
Does loading the fpc_rtl.dll really work ???

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

1. procedure foo(); stdcall; external rtl_dll name 'foo';

If you comment out the move line... then there is no reason to load the dll... so, there is no AV anymore.

Even without the move but with calling the simple foo, I get an AV error when loading the dll.

[Thaddy]

The move does not belong in an external library.Period.

[rvk]

The move does not belong in an external library.Period.

No, I agree, it doesn't.
But he's trying out things and can't understand that loading the dll itself is the problem. Not the move instruction itself.

(That's why I suggested to try just a simple foo procedure to see the move or messagebox itself wasn't the problem)

[paule32]

I know your concern's.
And AIKSF, the member data's that are used, and only when they are used, will be optimized by FPC.
So, when I (you) don't use any function, that resides otherwise in a .dll or .exe, the binary code of the given member will not include into the final result.
That is a great issue of FPC !

But my test's would be, what is, when the used members are outsourced into packages or dynamical libraries ?

Under Windows, you have two options:
- you can use so called .def initions files, which helps you (with the dlltool) to form a import library (*.a) that can be used to say, which member is in which dll. Okay you have set extra options during/for the link time, so the linker LD.exe can resolve the references.
- you can use so called "external" directives under FPC, where you can mark a member as "extern", and you can labeled this external mark with a name, that is found in the dynamic library where the binary code for the member resides.

- or an other, third option would be, that all of your application's use a static library, which comes like the import libraries *.a.
But this option tend to grow down your computer memory, and waste space on your storage devices - becaus all the used member binary code is linking redundant. And the final result (either: *.exe, or *.dll) will be maintained a little bit uncomfortable.
On the one look: you have all members into the PE image file, but big memory waste.
On the other look: you are little bit more flexible, when you use .DLL file that share the memory of your .EXE application's that use this DLL. Because the used DLL is only one times loaded into the memory, and all EXE that use members multiple times, can get the data from one code base. It is on the next hand comfortable, that you can provide update DLL files, so you can have a core application, and the logic lay in one or more DLL.
This is the way, how modern Windows works.

[Thaddy]

FPC will never optimize away library functions. It will only  optimize it away - if so required - in a final executable.

[paule32]

Hello,
Today I had change the build.bat ch file a little bit, so the developer changes (that the directories fit) are minimized to a low level.
So, you can easily change the location's on yours develop machines.

FPC will create a DLL first, and in a second step a EXE.

I can not use the DLL.
But I can use the same code, to show a message box at the Windows Desktop.

In the current code (test1.pas) you can find TestTest procedure, declared as external.
You can find this external code in file: src/tests/fpc_rtl.pas.

In file test1.pas, on line: 37, the application stops without a message - error - no box.
But there is a MessageBox procedure in fpc_rtl.pas.
Why is that code not executeable ?

When I comment in line:37, all seems be okay.
The PE executable image seems be clear.
But on creating the dynamic library, I went into trouble.

I used fpc builtin tools to create the dll and exe.
Is there a magic to link against the fpc_rtl.dll ?

You can find the current source on my github.com account.

[rvk]

I can not use the DLL.

That's what I'm trying to tell you the whole time.
Your dll is not correct or it is corrupt because of the way you build it.

In file test1.pas, on line: 37, the application stops without a message - error - no box.

Do me a favor... You don't see a messsage... But can you look in the event log of Windows>Applications. You'll probably see the error 0x0005 AV in there.

But there is a MessageBox procedure in fpc_rtl.pas.
Why is that code not executeable ?

This was already determined in your other (first) topic, but you keep on opening other topics with problems relating to the same initial problem... Your dll isn't correctly formed (missing something/wrong name, of otherwise) due to your custom rtl. I don't know exactly why but the dl is the problem (I already tested that in the other topic because your custom rtl can load a correct dll but your problem dll can't be loaded by a standard non modified rtl fpc.)

When I comment in line:37, all seems be okay.

Yep... No call to the dll, no need to load the problem dll.

[paule32]

Hello,

to come to a end with this thread, I would point you to:
https://forum.lazarus.freepascal.org/index.php/topic,66802.msg513766.html#msg513766

There is my origin thread about my current problem.

Please follow the link above for answers.

@admin, please close this thread temporary.
Thank you very much, and I would apologies me for the cross-posting.