I have tried having the WebView2Loader.dll in the same directory as my executable. And I have also instead to tried to download the evergreen build from https://developer.microsoft.com/en-us/microsoft-edge/webview2/ and install it into my system (and have LoadLibrary find the DLL there instead)
In both cases the following happens. In my 32bit executable builds everything loads and works fine. In my 64bit executable my code:
Windows.LoadLibrary(PChar('WebView2Loader.dll'))
Gives this error:
%1 is not a valid Win32 application
I am on latest Windows 10 64bit
Any ideas what I can try...?
Related
I've uninstalled my RAD Studio 10.2.2 and installed 10.2.3 in my Win10 development VM. Along the way I uninstalled all the previous 3rd-party libs, including the Jedi GetIt packages, and per the instructions got rid of all the old Jedi source and DCP/DCLs. I'm attempting to install them back into 10.2.3 via GetIt. The JCL libs install fine, but when I try to install JVCL, the installation batch file hangs after compiling the installer and the VM comes to its knees. I rebooted, started taskmgr and watched as the batch file ran - it appears to go into a loop creating many instances of msgfmt. I've tried removing it all again, downloading and installing the 3.8 version myself and running the install batch file by itself, same problem; then backing up to the 3.6 version that had installed OK in 10.2.2, and it does the same thing. If I edit the batch file to skip the language-setup section, the batch file completes OK, but trying to re-run the GetIt update causes it to re-download and replace that batch file. :(
The installer does compile before the languages part of the batch file is reached, so I tried running the installer directly. I assume I'm not passing it cmd line info it needs, because it compiles the 64-bit libs fine but chokes immediately on compiling the 32-bit version of JvCore250.bpl with an unspecified compile error.
Anyone else run into this? Is a solution known?
Turns out to ultimately be a pathing problem. When multiple installations of the IDE exist on a machine (e.g. my VM has or previously had D2007, XE2 and 10.1 on it), the PATH environment variable can be too long - edit the PATH in the system to remove the old/stale paths. Then make sure that the library paths in the IDE includes $(BDSLIB)\$(PLATFORM)\release or you'll get "can't find RTL" when building the packages.
For me the problem is generated from the msgfmt.exe of dxgettext.
msgfmt.exe generates multilanguage messages, for a multilanguage support of jvcl installation.
For the specific problem of msgfmt.exe try to see this: dxgettext and Windows 10
I resolved the problem opened the install.bat file in jvcl folder, and I commented (with ::) every line where the msgfmt is executed.
Attention:
If you use getit I suppose you have to open the folder where jvcl is downloaded and search install.bat (I didn't use getit)
Instead I downloaded jvcl directly from github in my component folder, and I did what is written above in that folder.
electron-builder is calling 32bit installer causing paths point to WOW64 equivalents instead of the real x64 paths.
Process that calls installer is 64bit, then 32bit installer is called and eventually application that is "runAfterFinish" is 64bit.
How can I overcome this issue and force installer to call x64 version?
Tested on Windows 10, electron-builder 19.16.3
Builder ran with --x64 option gives output:
Building NSIS installer
Packaging NSIS installer for arch x64
Calling installer with ... /D=path argument would also solve the problem, but it is not taking this into account.
I don't know anything about electron builder but I do know that a 32-bit NSIS installer can install 64-bit programs.
Use SetRegView to change to the 64-bit registry view and use the macros in x64.nsh to turn filesystem redirection on and off.
Recently i got a chance to work on delphi 7. I just created a sample application which display a welcome message and that exe is working fine on Delphi machine. if i moved that exe to non-delphi machine(where delphi is not installed), it is throwing error as "The program can't start beause rtl70.bpl is missing from your computer. Try reinstalling the program to fix the problem".
if i follow the same process with Delphi 5, it is working fine.
You have built the program to rely on runtime packages. That means that each machine that needs to run the program needs to have the runtime packages available.
There are two solutions:
Distribute the runtime packages that you use alongside the executable.
Disable runtime packages and so build an executable that contains the runtime.
The runtime packages options are determined by settings specified in the project options.
Unless you have some compelling reason to use runtime packages, the second option is much simpler because it allows the executable file to stand alone, with no external dependencies.
I have the same c++ DLL project which is configured to be a 32-bit application in Visual Studio 2012. I'm using OpenCV 2.4.0, the 32-bit build and the matching static lib files.
Whenever I try to use the DLL on a second project, on a 64-bit machine, it fails ( the second project is also 32-bit), BUT when i run it on a 32bit machine, it runs fine.
The error i get on the 64-bit machine happens exactly when i try to load the DLL which uses OpenCV, and here it is:
An unhandled exception of type 'System.IO.FileNotFoundException'
occurred in TheApp.exe
Additional information: Could not load file or assembly
'TheDll.dll' or one of its dependencies. The specified module
could not be found.
The DLL is placed into the x86 folder from the current working directory, and it is referenced from there.
When we are using delphi-10 exe we are getting below issue,but i couldnt find this file in my machine where I installed delphi10
"This application failed to start becuase rtl140.bpl was not found.Re-installing the application may fix this problem"
Your executable is compiled with runtime packages and requires them to run; you should deploy them on the target computer during installation. Alternatively, you could turn off runtime packages (compiler options) and have a stand-alone executable.
On a computer where Delphi is installed the runtime packages should be installed in the system directory; Delphi IDE itself is compiled with runtime packages.