alank2

Thank you everyone; I'll dig into this some more with your ideas.

The DLL has: #pragma argsused int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved) { if (reason==DLL_PROCESS_ATTACH) { Application->Initialize(); Form1=new TForm1(NULL); } else if (reason==DLL_PROCESS_DETACH) { if (Form1!=NULL) { delete Form1; Form1=NULL; } } return 1; } The attach section works fine. The Form1 is created and works great. If I omit the cleanup in the detach section, no error, but if I include the above I get the 0x0eedfae exception when closing the application that uses the DLL. Any ideas on why? Could the Form1 have already been deleted/cleaned up before the DllEntryPoint is called with DLL_PROCESS_DETACH?

Unfortunately there is no Clear() method. When I try to see what the methods are and type c, this is all it shows:

This is for C++ Builder, but I would think there is a Delphi way to do it that would translate, so I'm asking how you would clear it in Delphi and/or cppb. It says it is "Property Customheaders:UnicodeString", but I can't set it using: nhc->CustomHeaders=""; I am setting it using: nhc->CustomHeaders[name]=value; But, if I want to clear out any custom headers and start again, how do I do that?

It occurred to me that what is preferred is for the floating point status word to stay the way it was before loading the Embarcadero DLL (newer or older), so I came up with this to be called in the MSVC DLL after all Embarcadero DLL's are loaded. This will set and clear the bits I found to have changed between not loading and then loading the Embarcadero DLL for older or newer compilers. void fix_embarcadero_fpsw() { unsigned int x86_cw; //fix embarcadero changes to floating point status word __control87_2(0x1001c, 0x5001c, &x86_cw, NULL); }

I'm guessing there is something that runs when the DLL is loaded that makes the change. When I was having the original problem, merely doing a LoadLibrary was enough to cause the problem (whether I had a DllEntryPoint function or not). I'm assuming there is some sort of runtime initialization that is executed when the DLL is loaded irregardless of any of its functions being executed. Would this mean that I have to read the floating point value in the code that loads the DLL first (before the DLL is loaded)? And if so, that code is msvc, would I have to use this function to get the value before loading the DLL? https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/control87-controlfp-control87-2?view=msvc-170 In the case of the fix, I had called System::Set8087CW(0x133f); in the DllEntryPoint / DLL_PROCESS_ATTACH to correct it, so this must be after it is changed by the runtime initialization presumably?

You have figured it out Remy!!! Good work! Superb!!! Thank you! I added System::Set8087CW(0x133f) to my DLL and rebuilt it in 10.2 - no crash. Remark it out, back to the crash. This brings up a question #1 - is the original value (whatever it was set to before loading the DLL changes it) stored somewhere (could it be Saved8087CW)? I'm not sure I'd want a DLL changing the floating point behavior of a program just because it is loaded. Also, should I do an Application->Initialize() or not in the DllEntryPoint/atttach? Question #2 - What does Application->Initialize() do? int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved) { if (reason==DLL_PROCESS_ATTACH) { //Application->Initialize(); //Application->MessageBox(L"test",L"test",MB_OK); System::Set8087CW(0x133f); } else if (reason==DLL_PROCESS_DETACH) { } return 1; }

Is there a way to hit the Quote button and split into multiple quotes you can respond to? >You can call the Form's Update() method to force an immediate repaint. Will try this. >That implies your EXE is calling the DLL functions in a loop that is not processing your UI's message queues in between calls into the DLL. That is not a good design choice, especially for a DLL with a UI. I would suggest either: > moving your DLL's UI into a worker thread with its own message loop. > having the DLL export a function that the EXE can call periodically to pump your UI's message queue. > If the EXE has its own UI, then simply break up the EXE's logic to work asynchronously so its own message loop can also service your DLL's UI. I did have a processmessages function exported that would call processmessages, is this what you mean by the bold suggestion here? >Have you considered using the Remote Debugger? I've never used but, but will have to look into it! >Now we're getting somewhere useful. RAD Studio 12.0 did make changes to how it handles floating-point exceptions: >https://docwiki.embarcadero.com/RADStudio/Athens/en/What's_New#Disabling_Floating-Point_Exceptions_on_All_Platforms >On older versions, sometimes you do need to adjust the exception masks manually. Particularly for MSVC compatibility. How would I do that? Adjust these: Default8087CW, DefaultMXCSR, DefaultFPSCR, and DefaultFPSCR Somehow in the older compiler version?

Also, thanks for the tip about dumpbin and lib to make an import library - that is much easier than what I was doing. I found an example at this link: https://stackoverflow.com/questions/9946322/how-to-generate-an-import-library-lib-file-from-a-dll ... and expanded it to allow specifying an alternate output lib filename, some error checking, and returning an errorlevel: buildlib_msvc.bat One may have to change the dumpbin/lib path (or eliminate it if running from a MSVC developer prompt). @echo off rem check for 2 options only if empty%1==empty goto badopt if empty%2==empty goto badopt if not empty%3==empty goto badopt rem make sure dll exists if not exist %1 goto dlldoesnotexist rem delete old lib file if it exists if exist %2 del %2 if exist %2 goto cantdeleteoldlib rem add msvc path for dumpbin/lib if empty%MSVC_PATH_ADDED%==empty SET PATH=C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\;%PATH% if empty%MSVC_PATH_ADDED%==empty SET MSVC_PATH_ADDED=yes rem make lib (got this from someones example at stackoverflow) setlocal enabledelayedexpansion for /f "tokens=1-4" %%1 in ('dumpbin /exports %1') do ( set /a ordinal=%%1 2>nul set /a hint=0x%%2 2>nul set /a rva=0x%%3 2>nul if !ordinal! equ %%1 if !hint! equ 0x%%2 if !rva! equ 0x%%3 set exports=!exports! /export:%%4 ) for /f %%i in ("%1") do set dllpath=%%~dpni lib "/out:%dllpath%.lib" /machine:x86 /def: %exports% if errorlevel 1 exit /b 1 rem make sure new lib exists if not exist %1 goto didnotproducenewlib rem rename lib file to specified lib filename ren "%dllpath%.lib" %2 rem remove exp file if exist "%dllpath%.exp" del "%dllpath%.exp" rem success exit /b 0 :badopt echo ERROR: Specify buildlib_msvc name.dll name.lib exit /b 1 :dlldoesnotexist echo ERROR: %1 dll does not exist exit /b 1 :didnotproducenewlib echo ERROR: Did not produce new %2 lib exit /b 1 :cantdeleteoldlib echo ERROR: Can't delete old %2 lib exit /b 1

>They are using the same DLL instance? I probably didn't explain it clearly enough. >That is not how you should make the import lib for MSVC. Use MSVC's command-line DUMPBIN and LIB tools to create a new import lib from the DLL itself. >Use DUMPBIN to create a .DEF file for the DLL's exports, and then use LIB to generate a import lib from the .DEF file. I haven't tried this method yet, but will look into it. >Which items are you referring to exactly? There is nothing "bold" in what you showed. I had bolded the exports I didn't ask for, but it didn't paste in. >You really should not be calling Application->ProcessMessages() at all. I have to or it won't update the form properly. If I just call Show for example and skip the ProcessMessages, it won't paint it properly. If I don't call ProcessMessages, it won't process a click on the cancel button that I can read. >What is the actual crash? What is the error message, verbatim? Does the crash happen while the DLL is being loaded into memory, or inside of DllEntryPoint()? >Have you tried debugging the DLL in the IDE? Configure your DLL project with your MSVC app exe as its Host. Then put breakpoints in the DLL code as needed. >When you run the DLL project, it will execute the MSVC app, which will then load your DLL, and the debugger should attach to it so it can step through the DLL code normally. The application is an annoying one to install and is running in a VM where the compiler is not. I don't want to install it on my dev machine. The error is a code that c000008e that a search says is a floating point divide by zero error. I'm assuming it is just some type of crash. I just built the real DLL (not an empty stub) and with 12.2 it fully works with no problems. With 13.3 it crashes just like it did with 10.3. I have to think they must have fixed something to make it work in 12.2. Thank you for the help - it is greatly appreciated!

I'll need to work through your email questions Remy, but in the meantime, I found that a new DLL (VCL, multithreading) will also fail on all versions I tried until I got to 12.2 and there is does not fail. I'll try to compile it there and see if it works with everything enabled again. cppb6 - fails cppb10.3 - what I was testing on - fails cppb11.3 - fails cppb12.2 - does not fail interestingly - perhaps something was fixed.

Even if I make a brand new empty dll via file->new->other->dynamic library vcl with or without vc++ style dll set. I then set release and set it to link with dynamic rtl=false and link with runtime packages=false, the application will crash if I try to loadlibrary it only (no functions being executed).

I am building a DLL in cppbuilder 10.2 using the classic compiler with the static RTL. Sometimes I need a component I have available in cppbuilder to be called from microsoft visualc. Mostly this is working - I have a test application where I am opening a form, changing it, closing it, and that works fine. But another part of the application that uses this DLL crashes anytime the DLL is loaded. Even if I don't call any of its functions, just loading it is enough to cause the crash. To make a msvc compatible lib file for it, I also made a sample msvc project with the same function names/declarations that are empty. Then I can use that static lib file in the msvc project that loads the real cppb dll. If I test that empty msvc produced dll, the other part of the application does not crash. I'm trying to test to find out why it crashes. If I do a dumpbin /exports on the msvc empty stub project that just makes the lib, its empty dll shows this. 00000000 characteristics FFFFFFFF time date stamp 0.00 version 1 ordinal base 5 number of functions 5 number of names ordinal hint RVA name 1 0 00001010 displaydialog_dll_close = @_guard_check_icall_nop@4 2 1 00001020 displaydialog_dll_iscanceled = ___acrt_initialize 3 2 00001020 displaydialog_dll_isopened = ___acrt_initialize 4 3 00001010 displaydialog_dll_open = @_guard_check_icall_nop@4 5 4 00001010 displaydialog_dll_update = @_guard_check_icall_nop@4 Summary 1000 .data 1000 .rdata 1000 .reloc 1000 .rsrc 1000 .text Here is the dumpbin /exports from the cppb real dll that I want to use: What are these bold items that are also exported? They are not in my .def file. Section contains the following exports for displaydialog_dll.dll 00000000 characteristics 0 time date stamp 0.00 version 1 ordinal base 11 number of functions 11 number of names ordinal hint RVA name 2 0 00002C4C @@Unit1@Finalize 1 1 00002C34 @@Unit1@Initialize 3 2 00066A10 TMethodImplementationIntercept 6 3 00289B28 _Form1 4 4 0028110C ___CPPdebugHook 5 5 00289B14 dbkFCallWrapperAddr 8 6 00002AD8 displaydialog_dll_close 10 7 00002AE4 displaydialog_dll_iscanceled 11 8 00002AE8 displaydialog_dll_isopened 9 9 00002ADC displaydialog_dll_open 7 A 00002AD0 displaydialog_dll_update Summary 18000 .data 1000 .didata 1000 .edata 4000 .idata 37000 .reloc 8000 .rsrc 280000 .text 1000 .tls Code from my cppb dll: // Important note about DLL memory management when your DLL uses the // static version of the RunTime Library: // // If your DLL exports any functions that pass String objects (or structs/ // classes containing nested Strings) as parameter or function results, // you will need to add the library MEMMGR.LIB to both the DLL project and // any other projects that use the DLL. You will also need to use MEMMGR.LIB // if any other projects which use the DLL will be performing new or delete // operations on any non-TObject-derived classes which are exported from the // DLL. Adding MEMMGR.LIB to your project will change the DLL and its calling // EXE's to use the BORLNDMM.DLL as their memory manager. In these cases, // the file BORLNDMM.DLL should be deployed along with your DLL. // // To avoid using BORLNDMM.DLL, pass string information using "char *" or // ShortString parameters. // // If your DLL uses the dynamic version of the RTL, you do not need to // explicitly add MEMMGR.LIB as this will be done implicitly for you #include <vcl.h> #include <windows.h> #pragma hdrstop #include "Unit1.h" #pragma argsused int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved) { if (reason==DLL_PROCESS_ATTACH) { Application->Initialize(); //DEBUG i've tried it with and without this no difference still crashes } else if (reason==DLL_PROCESS_DETACH) { } return 1; } //i've tried remarking out all of the below code leaving only the empty function declarations, no difference still crashes //none of these functions even have to be called for it to crash, if the DLL is linked in that is enough extern "C" void __cdecl displaydialog_dll_update(const char *AMessage, const bool ACancelEnabled) { //do nothing if closed if (Form1==NULL) goto end1; //set message Form1->MMessage->Text=AMessage; //set cancelenabled Form1->SBCancel->Enabled=ACancelEnabled; Form1->cancelselected=false; end1: //process messages Application->ProcessMessages(); } extern "C" void __cdecl displaydialog_dll_close() { //do nothing if closed if (Form1==NULL) goto end1; //show form Form1->Close(); //delete form delete Form1; Form1=NULL; end1: //process messages Application->ProcessMessages(); } extern "C" void __cdecl displaydialog_dll_open(const char *AMessage, const bool ACancelEnabled) { //close if opened displaydialog_dll_close(); //create form Form1=new TForm1(NULL); //update message and acancelenabled displaydialog_dll_update(AMessage, ACancelEnabled); //show form Form1->Show(); //process messages Application->ProcessMessages(); } extern "C" bool __cdecl displaydialog_dll_iscanceled() { bool ret; //do nothing if closed if (Form1==NULL) { ret=false; goto end1; } //process messages Application->ProcessMessages(); //is canceled ret=Form1->cancelselected; end1: return ret; } extern "C" bool __cdecl displaydialog_dll_isopened() { bool ret; //do nothing if closed if (Form1==NULL) { ret=false; goto end1; } //process messages Application->ProcessMessages(); //is opened ret=true; end1: return ret; } Yes, I know I could probably come up with a similar solution in msvc, but I am more familiar with cppbuilder. Also, do this same approach with other components from cppbuilder that I also need like tnethtppclient. Any ideas on what to try to troubelshoot this further?

Thank you for the help rvk (and everyone in this thread!), instead of a loose end I now have a reason for why it is doing what it does. Going forward I'll ignore the status text always and just go with the result code. What made me nervous about this is that the status code itself is also retrieved from the same function as text and then later converted to an integer, so I'm not sure why this is an issue for status text, but not status code. Hopefully going forward it won't be.

I noticed this as well. I don't usually use the /install or /uninstall options but instead use Inno setup and sc.exe to stop/remove/install/start services. I usually (and I don't think it is the right way as Remy pointed out to me in another thread, I still need to do some testing on it to change) implement a ServiceExecute with a message loop that runs until the service is stopped, so something like this; while (!Terminated) //do not quit if process is running until it is finished { ServiceThread->ProcessRequests(true); Sleep(250); } If I add this to the above service, it doesn't add the OK from local execution of "project1 /install", but it does for some reason for "project1 /uninstall". How would you do this? Exactly. I know the local system account does change the environment that a service runs it as far as rights go, but I don't know what this would have a change in the WinHttpQueryHeaders().