I am using a WINCE framework for development called WINDEV.
This framework has some DLLs that are to be loaded, but on some WINCE platforms, the loading (tested with a c program with the LoadLibraryEx instruction) does not work ....
The results vary from one platform to another ....
What are the hypothesis to be checked ?
Thank for your help.
What does exactly mean "does not work"?
According to MSDN, LoadLibraryEx on failure returns NULL, and "To get extended error information, call GetLastError."
Some ideas:
- is the DLL you are trying to load in the same directory of the executable?
- is the DLL a valid Windows CE binary?
- does LoadLibraryEx work if you try to load some known system DLL?
Sorry, without more details I cannot think of anything more.
Since Windows CE is a modular OS not all Windows CE platforms include all the components. It might be that your Dll is dependent on one of these components and thus fails to load.
As Benedetto suggested, get the last error and add the information to the question.
You can also use DependencyWalker to see what Dlls your library depends on so you can check whether they are available on the non cooperatives platforms.
Related
I use Cygwin to build source code to DLL used by windows app.
When I use GCC core / GCC g++, the app crash if it calls function (which includes printf or malloc) in DLL.
When I use Mingw64-x86_64-gcc-core / Mingw64-x86_64-gcc-g++ it reports error like sys/socket.h：No such file or directory.
Can anyone explain how to do it? Thanks.
The first problem is due to the tentative to build a stand alone DLL (not depending on cygwin1.dll) using cygwin only specific tools.
You have collision between multiple malloc and other C library call present in cygwin1.dll.
The second is due to the fact that sys/socket.h does not exist on Windows
see for possible solution:
Using sys/socket.h functions on windows
So you need to define what is your target : Cygwin/Posix or Windows and choose programming style and tools accordingly, you can not mix.
I'm on windows 7 64bit, trying to run some software and I am getting an error indicating that I am missing qt5widgets.dll. I tried to find this dll from different websites but didn't have any luck. Where can I find the files to resolve this dependency ?
You should contact the person who gave you the application. The necessary libraries should have been included in the distribution.
Failing that, you may want to try here you will need to get the version that the application is expecting, and potentially match the compiler that was used to build the application.
You would expect the required dll's would come bundled with the application. This application is a QT application and the aforementioned dll's can also be found at QT5 official website.
I've compiled haskell program which uses wxHaskell library, now I would like to know how to make it run on other machines which doesn't have wxHaskell installed. Of course I can see errors and I can copy dlls written in output and copy them to that machine but what is professioal sollution, can I write any installer or something like that?
thanks for help
You will need to fully statically link your executable. How to do this varies from system to system, but in general involves passing the -static flag to GHC, and -optl-static to your linker.
If you use the recent cabalized wxHaskell implementations, it's pretty easy, since almost everything is statically linked.
I use InnoSetup, which is Open Source, and works very well. My script needs at least the following:
AppName=My Wonderful Application
AppVerName=My Wonderful Application 0.1.13
CreateAppDir=yes
DefaultDirName={pf}\MyWonderfulApplication
[Files]
Source: "path\to\your\wxWidgets.dll"
Source: "path\to\msvcrt.dll"
Source: "path\to\your\application.exe"
All of the paths except DefaultDirName are paths on your development machine.
The key items are your wxWidgets DLL (may be multiple DLLs, depending on how you built wxWidgets - I recommend and use the monolithic option, which creates a single DLL, wxmsw28u_gcc_custom.dll) and your application binary.
If you are linking to any other libraries, you will need them as well. Many 3rd party libraries on Windows require msvcrt.dll, which is why I've mentioned it.
Thanks to the gurus at StackOverflow. You guys are awesome. I posted on question on detecting idle time on a Compact framework application and got answers very quickly. When I tried the suggested solution on my Windows XP development box, I get this error
Unable to load DLL 'coredll.dll': The
specified module could not be found.
(On Windows XP)
After googling for sometime I understood that OpenNETCF libraries are trying to launch coredll.dll to detect the idle time but this dll is shiped with only Windows Mobile OS. As we are developing the application on a Windows XP PC and dont have access to Windows CE device now, we are struck with the problem.
Is there any way to get coredll.dll on Windows XP? Any other solution to this problem?
Updated: we are targeting the application for device running on Windows Mobile 6 Professional
I'm confused. The question was specifically about Compact Framework, which is for Windows CE. If you don't have your target hardware yet, then use an emulator.
In this specific case, the SDF is not P/Invoking to do this, it's using an IMessageFilter implementation. You could easily do the same for the desktop.
But that said, you simply can't develop a CF application targeting XP. What that means is that if you create your app using the full framework, targeting the desktop, and expect it to just run when you get your CE device, you're in for a big surprise. If targeting both OSes is a design goal, then there's a lot of work to be done, and most UI stuff is not transferrable (I'd actually recommend using different UI assemblies for the two targets and common business logic).
EDIT1
I guess to more fully answer the question of "can I get coredll.dll for my desktop?" the answer is a resounding "no". There are a multitude of reasons this wouldn't work (it's in ROM, it's hardware dependent, it's not actually a file, but fixed up to execute in place, it's compiled for a different OS, it may be compiled for a totally different processor, etc).
You have a couple options. You could try to create a desktop version of coredll.dll that exported all of the functions you want and proxies them to the kernel32, user32, etc DLLs. That's a boatload of work (been there, tried that).
You could try to write code that will work for both platforms. Doable, but also quite challenging.
The short of it is, unless you absolutely must target both, you don't want to try to. Get an emulator, virtual PC or some sort of eval system, and target that.
You can't run OpenNetCF in a Windows PC. You need to use a Windows CE emulator. This comes with the Windows CE SDK.
Write code that works for both platforms.
In our solution anything that is going to touch the platform is abstracted out to different objects. Therefore we have a IPlatformServices object (that returns stuff like IPowerManagement, IPrinter etc) we have two different implementations a PCPlatformServices and a CEPlatformServices and the one returned is based on the Environment.PlatformID value. In your scenario you want 2 different IdleDetector objects one for CE and one for Desktop. Aye its a bit of a pain to identify and abstract all this but you will need to do this is you want compatability between the two different platforms.
Our "PCPlatformServices" is mainly mocks in our case as we only want desktop compatibility to test things more quickly that don't interact with the hardware (like app code / business logic)
We need to interface to 3rd party app, but company behind the app doesn't disclose message protocol and provides only Windows DLL to interface to.
Our application is Linux-based so I cannot directly communicate with DLL. I couldn't find any existing solution so I'm considering writing socket-based bridge between Linux and Windows, however I'm sure it is not such a unique problem and somebody should have done it before.
Are you aware of any solution that allows to call Windows DDL functions from C app on Linux? It can use Wine or separate Windows PC - doesn't matter.
Many thanks in advance.
I wrote a small Python module for calling into Windows DLLs from Python on Linux. It is based on IPC between a regular Linux/Unix Python process and a Wine-based Python process. Because I have needed it in too many different use-cases / scenarios myself, I designed it as a "generic" ctypes module drop-in replacement, which does most of the required plumbing automatically in the background.
Example: Assume you're in Python on Linux, you have Wine installed, and you want to call into msvcrt.dll (the Microsoft C runtime library). You can do the following:
from zugbruecke import ctypes
dll_pow = ctypes.cdll.msvcrt.pow
dll_pow.argtypes = (ctypes.c_double, ctypes.c_double)
dll_pow.restype = ctypes.c_double
print('You should expect "1024.0" to show up here: "%.1f".' % dll_pow(2.0, 10.0))
Source code (LGPL), PyPI package & documentation.
It's still a bit rough around the edges (i.e. alpha and insecure), but it does handle most types of parameters (including pointers).
Any solution is going to need a TCP/IP-based "remoting" layer between the DLL which is running in a "windows-like" environment, and your linux app.
You'll need to write a simple PC app to expose the DLL functions, either using a homebrew protocol, or maybe XML-RPC, SOAP or JSON protocols. The RemObjects SDK might help you - but could be overkill.
I'd stick with a 'real' or virtualized PC. If you use Wine, the DLL developers are unlikely to offer any support.
MONO is also unlikely to be any help, because your DLL is probably NOT a .NET assembly.
This is a common problem. Fortunately, it now has a solution. Meet LoadLibrary, developed by Tavis Ormandy:
https://github.com/taviso/loadlibrary
I first stumbled across LoadLibrary in an article on Phoronix by Michael Larabel:
A Google researcher has been developing "LoadLibrary" as a means of
being able to load Windows Dynamic Link Libraries (DLLs) that in turn
can be used by native Linux code.
LoadLibrary isn't a replacement for Wine or the like but is intended
to allow Windows DLL libraries to be loaded that can then be accessed
by native Linux code, not trying to run Windows programs and the like
on Linux but simply loading the libraries.
This project is being developed by Tavis Ormandy, a well known Google
employee focused on vulnerability research. He worked on a custom
PE/COFF loader based on old ndiswrapper code, the project that was
about allowing Windows networking drivers to function on Linux.
LoadLibrary will handle relocations and imports and offers an API
inspired by dlopen. LoadLibrary at this stage appears to be working
well with self-contained Windows libraries and Tavis is using the
project in part for fuzzing Windows libraries on Linux.
Tavis noted, "Distributed, scalable fuzzing on Windows can be
challenging and inefficient. This is especially true for endpoint
security products, which use complex interconnected components that
span across kernel and user space. This often requires spinning up an
entire virtualized Windows environment to fuzz them or collect
coverage data. This is less of a problem on Linux, and I've found that
porting components of Windows Antivirus products to Linux is often
possible. This allows me to run the code I’m testing in minimal
containers with very little overhead, and easily scale up testing."
More details on LoadLibrary for loading Windows DLLs on Linux via
GitHub where he also demonstrated porting Windows Defender libraries
to Linux.
Sometimes it is better to pick a small vendor over a large vendor because the size of your business will give you more weight for them. We have certainly found this with AV engine vendors.
If you are sufficiently important to them, they should provide either a documented, supported protocol, a Linux build of the library, or the source code to the library.
Otherwise you'll have to run a Windows box in the loop using RPC as others have noted, which is likely to be very inconvenient, especially if the whole of the rest of your infrastructure runs Linux.
Will the vendor support the use of their library within a Windows VM? If performance is not critical, you might be able to do that.
Calling the DLL's functions themselves is of course only the tip of the iceberg. What if the DLL calls Win32, then you'd have a rather massive linking problem. I guess Wine could help you out there, not sure if they provide a solution.
IMO, the best bet is to use Sockets. I have done this previously and it works like a charm.
An alternate approach is to use objdump -d to disassemble the DLL, and then recompile/reassemble it. Don't expect to be able to recompile the code unedited. You might get pure, unadulterated rubbish, or code full of Windows calls, or both. Look for individual functions. Functions are often delimited by a series of push instructions and end with a ret instruction.