A.M. Hoornweg

If the problem is just that the cdecl function needs to be in an external module, maybe it's possible to work around that. It may sound counter-intuitive, but it's perfectly possible to export a function contained in an *.exe project and then call it from a DLL loaded by the executable. I see no reason why the executable shouldn't be allowed to import a function that it exports itself. Program test; uses windows; function somefunction:integer; cdecl; export; begin result:=1; outputdebugstring(pchar('Hello World')); end; Exports somefunction; end;

One advantage is that it's way less work server-side. If anything goes wrong, you need not worry too much about how to inform the client because that information is already contained in the exception that was thrown by whatever action failed. The stack is unrolled automatically just like in regular Delphi apps and the exception information is automatically propagated to the client. Client-side, a remote procedure call is used like any other Delphi call. In the case of an error, you use structured exception handling and use the exception type as a criterium for how the client should proceed. try server.executequery(query) except on e:exception do begin if e is eCommsError then //did the internet connection fail? If so, client should try again later. ... else if e is eDatabaseError then showmessage(format('The server really didn''t like this query, this is wrong with it: (%s) "%s"',[e.classname, e.message])) else ... end; end;

The disadvantage of that is that it doesn't tell you in detail what went wrong on the server. It is also tedious, the server needs to CATCH exceptions and convert them into something meaningful (an error code?) to pass back to the client, hopefully yielding sufficient information. If the framework itself is designed in such a way that it can pass exceptions back from server to client, the client will re-raise the same exception type (eOverflow, eConvertError, eInOutError, eListError...) with (hopefully) the server's error address in the error message so you can easily find the root cause. It also simplifies server-side development enormously; if something goes wrong on the server, it can simply raise an exception and it will be passed back to the client.

I use Remobjects Remoting SDK as a middleware and that is perfectly capable of passing an exception that happens in a remote procedure call back to the client without hanging. The exception is then raised in the client.

Thank you very much!

I use MMX code explorer but I can't find the option to do this, can you point me to it? Thanks in advance!

Hello World, does anyone know of an IDE plugin or other tool that will analyze the interface section of a unit and expand the unit names with their full namespaces, such as "rtl, vcl, db" etc ? Thanks in advance!

Please try to disable "code inlining control" in the compiler settings and see if the problem disappears.

FOUND! The L902 linker error disappears if I set the compiler switch "code inlining control" to OFF! I can reproduce this in several 32-bit programs that had this problem. Kudos to my colleague Ralf Claussen who discovered this by chance.

I want "F2084 Internal Error L902" gone !!!

Hello all, I have ported a large project (32-bit, 1.4 million LOC) from Delphi 11 to Delphi 12 (enterprise). Performing a "full build" works fine, but a "make" produces linker error L902 every time; now just imagine you're debugging something and have to do a full build all the time. It's simply no fun. I have never had this problem in Delphi 11. Is there any way I can circumvent this problem ?

What are you talking about??? I'm not compressing any EXEs. I'm just preventing that 30-40% of unused stuff gets linked into them (it would be nice if Delphi's linker had such an option). And of course I use highly compressed setups.

I have *always* used installers. Nowadays executable size is not much of an issue anymore, thanks to better networks. But in a not so distant past I had to regularly push software updates to locations that were using T&T Inmarsat Mini-M satellite terminals. Imagine the slowest and most expensive connection imaginable, 2400 bps, costing like 5 euros per minute. I'm glad those days are over.

It adds up in some projects consisting of dozens of dlls and executables. I had to cope with deployment over slow connections paid by data volume until quite recently.

The problem with using UPX is the following. Normally Windows would open an executable file using a "memory mapped file" mechanism instead of bluntly allocating memory and loading the contents. This allows the Windows virtual memory manager to efficiently "page in" sections of the executable as needed (on demand paging), improving performance and minimizing memory use. If the file is compressed using UPX, execution starts in the UPX loader stub which immediately allocates a big block of memory and extracts the executable into that before proceeding with the "real" execution. This simply wastes precious resources.