I lost in Code ...

[paule32]

Hello,
I have the following Code that concerns me:

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

1. type
2.   TExitProcedure = procedure;
3. const
4.   MaxExitProcs = 64;
5. var
6.   ExitProcedure: array[0..MaxExitProcs - 1] of TExitProcedure;
7.   ExitProcedureCount: Integer;
8.  
9. procedure AddExitProc(P: TExitProcedure); stdcall; export;
10. begin
11.   if ExitProcedureCount < MaxExitProcs then
12.   begin
13.     ExitProcedure[ExitProcedureCount] := P;
14.     writeln('add: ' + inttostr32(ExitProcedureCount));
15.     ExitProcedureCount := ExitProcedureCount + 1;
16.   end else
17.   begin
18.     writeln('too many exit procedures.');
19.     Halt(1);
20.   end;
21. end;
22.  
23. procedure fpc_do_exit; [public, alias: 'FPC_DO_EXIT'];
24. var
25.   p: TExitProcedure;
26.   tempi: Integer;
27. begin
28.   fpc_finalizeunits;
29.  
30.   tempi := ExitProcedureCount;
31.   repeat
32.     writeln('tempi: ' + IntTostr32(tempi));
33.     p := TExitProcedure(ExitProcedure[tempi]);
34.     if p <> nil then
35.     begin
36.       writeln('call: ' + IntToStr(tempi));
37.       p;
38.       tempi := tempi - 1;
39.     end;
40.   until tempi = 0;
41.  
42.   ExitProcess(ExitCode);
43. end;
44.  

But I get:

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

1. Reading symbols from test.exe...
2. (gdb) r
3. Starting program: T:\a\test.exe
4. [New Thread 20372.0x5b5c]
5. [New Thread 20372.0x5a38]
6. [New Thread 20372.0x567c]
7. DLL attach: ok
8. start
9. add: 0
10. add: 1
11. tempi: 0
12. [Thread 20372.0x567c exited with code 0]
13. [Thread 20372.0x5a38 exited with code 0]
14. [Thread 20372.0x5b5c exited with code 0]
15. [Inferior 1 (process 20372) exited normally]

Take a look to "tempi"...

[d2010]

Hello,
I have the following Code that concerns me:

I do not understand ,your wish.
I break my application to many tines unit/s even are more empty,
My hint is = You can add halt or exitproc at any unit.pp, without ExitProc redirect.

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

1. Initialization
2. Begin
3.       ValueName[0]:=#0;
4.       ValueName[1]:=#0;
5.       ValueName[2]:=#0;
6. End;
7.  
8. Finalization
9. Begin
10.      halt;
11. End;                  
12. End.
13.  

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

1. Unit hc_tram48;
2. Interface
3. Uses hc_type48;
4. Var rezultat:string='';
5.     lsp2c_prep:record
6.                argc:word;
7.                argv:array [Word] of hc_type48.NavTree;
8.             end;
9. Function hctram_boot:Integer;
10. Function vla_getvar_treemax:integer;
11. Implementation
12.  
13. Function hctram_Boot:Integer;
14. Begin  result:=sizeof(NodeType);
15.        fillchar(lsp2c_prep,sizeof(lsp2c_prep),0);
16.        fillchar(lsp2c_prep,sizeof(lsp2c_prep),Byte(0));
17.        with jcs_multianewarray0tx8  do fillTtf:='';
18. End;
19. {--}
20. Function vla_getvar_treemax:integer;
21. Var iterator:integer;
22. Begin result:=0;
23.       for iterator:=0 to lsp2c_prep.argc do
24.          result:=result+sizeof(lsp2c_prep.argv[iterator]);
25. End;
26. {--}
27. Initialization
28.   hctram_Boot();
29. Finalization
30. End.
31.  

[paule32]

you don't understand my concerns:

- in Line 15, I do a increment of ExitProcedureCount
- in Line 30, I set tempi with ExitProcedureCount
  and here, tempi is zero, instead one: 1

- I had tried to play with the Optimized Options like -O1 -O2 ...

but all give me the same result

[ASerge]

Take a look to "tempi"...

In this code, you never call AddExitProc, so ExitProcedureCount is always zero, as a result, the tempi variable is also zero.

[paule32]

sorry for confuse you.
the code looks like:

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

1. procedure CleanUp1;
2. begin
3.   WriteLn('cleanup1 called.');
4. end;
5.  
6. procedure CleanUp2;
7. begin
8.   WriteLn('cleanup2 called.');
9. end;
10.  
11. begin
12.   writeln('start');
13.  
14.   AddExitProc(@CleanUp1);
15.   AddExitProc(@CleanUp2);
16.  
17.   Halt(2);
18. end;

(see Line 14 of prior post)

[paule32]

hui... what a mess...
I solved the Problem by using getter Function.

[Martin_fr]

No idea what is the cause. But, an idea how to debug.

- Start the App.
- hit a breakpoint (when you first add an exit proc, or before).
- Set a Watchpoint (data breakpoint) on: ExitProcedureCount  (monitor for "write" access, or "both")
  (must be in scope, but as a global var it should be...)
- Run

Now it will always stop, when the variable changes (or even if it is read). So it should stop when you increment it. And if it gets reset to 0 (by any means whatsoever) then it breaks too.

As long as it is all using the same var, it should tell you where it is set to zero.

[paule32]

Thank you for the step by step guide.
I don't familar with all the details of Windows...
but for me it could be clear now:

I have double Code:
- 1 times for export's (DLL code outsource), and
- 1 times for import's and normal EXE code where the second manner is a stub like code that call the exports in the DLL.

Then I thinking, I have two processes:
- 1 times the EXE, and
- 1 times the DLL

So I thinking next that I access with the EXE the right Functions, but by using the Functions, the DLL global vars will be override by the EXE one (because it is the Idea of DLL that many EXE can access one DLL - and when a second Process access the global DLL Code, it will be override).

So, I was thinking to get a Function get, that get the Process attached Variable, and get done with that.

It seems that some details of DLL and EXE becomes in one Process, so you (me) can use a common space together - like you access a new Instance of an Object - you will get a new Pointer - and with this Pointer, you (me) can bind other (global ?) Pointers.

Some wired to explain for me, but it works, now.

[cdbc]

Hi
A dll gets loaded into the process' space, BUT you have to make sure, that they SHARE the SAME MEMORY-MANAGER.
Otherwise, you're stuck with pure C-API & boundries.
Regards Benny

[Khrys]

So I thinking next that I access with the EXE the right Functions, but by using the Functions, the DLL global vars will be override by the EXE one (because it is the Idea of DLL that many EXE can access one DLL - and when a second Process access the global DLL Code, it will be override).

Using DLLs many different processes can load the same shared code - but DLLs by themselves can not used to share data between processes.
Think of a DLL as an actual, physical library with books - many people may borrow some books and memorize the contents, but they aren't allowed to just scribble stuff onto the pages - that would make the librarian very unhappy 

DLLs can't live on their own, they need a host (kind of like a parasite  ) that loads them into their address space. There is no system-wide global instance of any given DLL, but there may exist many copies spread across (and living inside) many different processes.

With that being said, I'm intrigued by your project with @Fibonacci. Are you trying to reimplement the RTL?

[paule32]

yes, I am on the way to reimplement the RTL on a way of using DLL Files.
This comes in many conversions from the past...
But I thinking on a light weight system, where the executables have a minimal size, by using DLL.

The actual DLL File has a size of 43 KB (with pre alpha classes for Forms) and the EXE File Demo comes with 14 KB - unpacked.

If you use UPX, then you can reach the half of the size on storages.

[Fibonacci]

With that being said, I'm intrigued by your project with @Fibonacci. Are you trying to reimplement the RTL?

I must say, again, that Im not a fan of this idea - RTL in a DLL. Im just watching. I already explained to Paule, that if there is a DLL, it needs to export everything, always, while a single exe pulls in only the code it actually uses, becoming significantly smaller, and that is the goal. Also, shipping two files instead of one is just another hassle.

[Thaddy]

One big single dll is indeed not a good idea, but with on demand dynamic loading it can be distributed over several dll's.
This is what the Windows OS does. Other  option is to wait until the DCU style packaging is finished.
For simple and small code, we already have KOL, which has its own rtl and optionally its own system.
Which gives you GUI applications from 14 (Delphi) or 40-50 KB (FreePascal)
Paule should study how KOL handles its system. (But note KOL uses old school objects, not classes and does not well mix with classes, because then the size comes back to standard. On  non-OOP it is almost fully compatible, though)
KOL 3.2.3 is available for FPC, but I did not check beyond FPC 3.0.0 for lack of time and basically I would probavly have to finally finish KOL 4.0 and FPC 3.2.2 and Trunk/Main. An advantage is that KOL is already 32 and 64 bit Windows. Paule only writes 32 bit code.

[440bx]

I think that putting the entire FPC RTL in a dll is a good idea.  Making it usable by any program might not be simple if the compiler insists on always including the RTL in the executable.

Having the RTL in a dll might even solve some problems in addition to sharing more code and making executables smaller.

All that said, I'm not fond of using UPX.

ETA:

it's rather unlikely that the entire RTL can be put in a dll given that functions like writeln cannot be accurately described as an export. 

[Thaddy]

I think that putting the entire FPC RTL in a dll is a good idea.  Making it usable by any program might not be simple if the compiler insists on always including the RTL in the executable.

It only relies on system, not the complete rtl.

Having the RTL in a dll might even solve some problems in addition to sharing more code and making executables smaller.

dll loading comes at a price and the memory footprint would be bigger, not smaller, although it may cosmettically look smaller.

All that said, I'm not fond of using UPX.

Agreed. UPX has also a penalty in unpacking, hence UPX is no longer adviced by FPC core since over 6 years ago.
It also triggers false positives frequently.

ETA:

it's rather unlikely that the entire RTL can be put in a dll given that functions like writeln cannot be accurately described as an export.

That is true for all compilerprocs/compiler magic, although some can be mitigated by wrapping OS calls, e.g. use wsprintf internally to wrap format() (as we do in KOL). OTOH suffers from the same dll issue since it depends on msvcrt.dll