I have some COM and some native dlls that are compiled for a Win CE device that I have. I would like to take a look at them, so I can create an application that references them and extends the functionality of some programs already on the device. When I open them with the Dependency Walker or Visual Studio 2008, both tell me that they are invalid DLLs. However, I'm fairly certain they are not corrupted, as I extracted them from the ROM of the device along with other files (bmps and the like) that are not corrupted. So I'm asking- are WinCE dlls fundamentally different than win32 dlls, and as such vs and depends is not reading them correctly? Or is something else going on?
Thanks
They are likely not corrupted, but tools that expect x86 images (as opposed to ARM, MIPS, etc) may give that misleading error when they encounter images compiled for a different processor. There are many similar tools which may help (PEDump and PEBrowsePro come to mind) scattered around the net, and since the PE format is portable (hence "portable executable"), one of them is bound to work.
In addition, some devices protect executables in ROM from being copied. It's possible the device corrupted your files on purpose when you copied them. A quick look in a hex editor should reveal this.
Dependency Checker will work with WinCE DLLs (I've used this quite often myself).
You can expect to get errors reported about missing dependencies, because Dependency Checker won't know where to find Coredll.dll & possibly the MFC DLLs because they aren't the same as the desktop ones. Once you educate Dependency Checker you can resolve these links too.
Otherwise, zildjohn01 is right that you sometimes can't copy executables or DLLs from the ROM of a WinCE device. It depends how the OS image is made: if the DLLs or EXEs are included as "MODULES" rather than "FILES" then you cannot copy them back off.
Related
I would like to know when do we need to place a file under
C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.
I had two DLL's, one for 32-bit, one for 64-bit.
Logically, I thought I'd place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.
To my surprise, it's the other way around! The 32-bit one goes into C:\Windows\SysWOW64, and the 64-bit DLL goes into C:\Windows\System32.
Very confusing stuff. What's the reason behind this?
I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.
SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.
This article explains a bit:
Windows x64 has a directory System32 that contains 64-bit DLLs (sic!).
Thus native processes with a bitness of 64 find “their” DLLs where
they expect them: in the System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does
the magic of hiding the real System32 directory for 32-bit processes
and showing SysWOW64 under the name of System32.
If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.
I should add: You should not be putting your dll's into \system32\ anyway! Modify your code, modify your installer... find a home for your bits that is NOT anywhere under c:\windows\
For example, your installer puts your dlls into:
\program files\<your app dir>\
or
\program files\common files\<your app name>\
(Note: The way you actually do this is to use the environment var: %ProgramFiles% or
%ProgramFiles(x86)% to find where Program Files is.... you do not assume it is c:\program files\ ....)
and then sets a registry tag :
HKLM\software\<your app name>
-- dllLocation
The code that uses your dlls reads the registry, then dynamically links to the dlls in that location.
The above is the smart way to go.
You do not ever install your dlls, or third party dlls into \system32\ or \syswow64. If you have to statically load, you put your dlls in your exe dir (where they will be found). If you cannot predict the exe dir (e.g. some other exe is going to call your dll), you may have to put your dll dir into the search path (avoid this if at all poss!)
system32 and syswow64 are for Windows provided files... not for anyone elses files. The only reason folks got into the bad habit of putting stuff there is because it is always in the search path, and many apps/modules use static linking. (So, if you really get down to it, the real sin is static linking -- this is a sin in native code and managed code -- always always always dynamically link!)
Ran into the same issue and researched this for a few minutes.
I was taught to use Windows 3.1 and DOS, remember those days? Shortly after I worked with Macintosh computers strictly for some time, then began to sway back to Windows after buying a x64-bit machine.
There are actual reasons behind these changes (some would say historical significance), that are necessary for programmers to continue their work.
Most of the changes are mentioned above:
Program Files vs Program Files (x86)
In the beginning the 16/86bit files were written on, '86' Intel processors.
System32 really means System64 (on 64-bit Windows)
When developers first started working with Windows7, there were several compatibility issues where other applications where stored.
SysWOW64 really means SysWOW32
Essentially, in plain english, it means 'Windows on Windows within a 64-bit machine'. Each folder is indicating where the DLLs are located for applications it they wish to use them.
Here are two links with all the basic info you need:
MSDN File System Redirector
SysWow64 Explained
Hope this clears things up!
System32 is where Windows historically placed all 32bit DLLs, and System was for the 16bit DLLs. When microsoft created the 64 bit OS, everyone I know of expected the files to reside under System64, but Microsoft decided it made more sense to put 64bit files under System32. The only reasoning I have been able to find, is that they wanted everything that was 32bit to work in a 64bit Windows w/o having to change anything in the programs -- just recompile, and it's done. The way they solved this, so that 32bit applications could still run, was to create a 32bit windows subsystem called Windows32 On Windows64. As such, the acronym SysWOW64 was created for the System directory of the 32bit subsystem. The Sys is short for System, and WOW64 is short for Windows32OnWindows64.
Since windows 16 is already segregated from Windows 32, there was no need for a Windows 16 On Windows 64 equivalence. Within the 32bit subsystem, when a program goes to use files from the system32 directory, they actually get the files from the SysWOW64 directory. But the process is flawed.
It's a horrible design. And in my experience, I had to do a lot more changes for writing 64bit applications, that simply changing the System32 directory to read System64 would have been a very small change, and one that pre-compiler directives are intended to handle.
Other folks have already done a good job of explaining this ridiculus conundrum ... and I think Chris Hoffman did an even better job here: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
My two thoughts:
We all make stupid short-sighted mistakes in life. When Microsoft named their (at the time) Win32 DLL directory "System32", it made sense at the time ... they just didn't take into consideration what would happen if/when a 64-bit (or 128-bit) version of their OS got developed later - and the massive backward compatibility issue such a directory name would cause. Hindsight is always 20-20, so I can't really blame them (too much) for such a mistake. ...HOWEVER... When Microsoft did later develop their 64-bit operating system, even with the benefit of hindsight, why oh why would they make not only the exact same short-sighted mistake AGAIN but make it even worse by PURPOSEFULLY giving it such a misleading name?!? Shame on them!!! Why not AT LEAST actually name the directory "SysWin32OnWin64" to avoid confusion?!? And what happens when they eventually produce a 128-bit OS ... then where are they going to put their 32-bit, 64-bit, and 128-bit DLLs?!?
All of this logic still seems completely flawed to me. On 32-bit versions of Windows, System32 contains 32-bit DLLs; on 64-bit versions of Windows, System32 contains 64-bit DLLs ... so that developers wouldn't have to make code changes, correct? The problem with this logic is that those developers are either now making 64-bit apps needing 64-bit DLLs or they're making 32-bit apps needing 32-bit DLLs ... either way, aren't they still screwed? I mean, if they're still making a 32-bit app, for it to now run on a 64-bit Windows, they'll now need to make a code change to find/reference the same ol' 32-bit DLL they used before (now located in SysWOW64). Or, if they're working on a 64-bit app, they're going to need to re-write their old app for the new OS anyway ... so a recompile/rebuild was going to be needed anyway!!!
Microsoft just hurts me sometimes.
When I try to register the 32 bit version of my C++ / ATL project with
regsvr32 project.dll
i'm getting this error:
LoadLibrary("project.dll") failed - The specified module could not be found
project.dll is my dll built using ATL on Visual Studio 10.
The 64 bit version registered fine.
What am I missing?
I have observed this exact same error, but the solution was not installing the redistributable. All the dependent DLLs were present on the system1 according to depends.exe.
In my case, the icon of KERNEL32.DLL was slightly red tinted. Depends.exe did not offer much explanation, but digging around revealed that one of the imported functions were missing from the DLL on the system. To see the imported functions, select the dependent DLL in the treeview and look for the import on the right panel. Order by the PI column to see the red icons of missing imports.
In my case, the missing function was a function that did not exist on my sad target operating system, Windows XP. Since my program did not directly depend on this function, I was able to get away with #defineing the following in my project:
#define WINVER 0x0501
#define _WIN32_WINNT 0x0501
Compiling with these macros made it so the function in question was not declared in the headers, and consequently not imported at load-time. Now I was able to use regsvr32. This of course is a very specific (and lucky) case. I did not depend on that import or any other newer APIs, so I could get away with retargeting the project. Were it not a system DLL, I would have needed to find a newer version which could easily lead to a need to update a whole sub-tree of the dependency graph. Or even worse, if I depended on the missing imports, some serious refactoring would be needed.
To sum it up, this error message2 can be caused by the following issues:
The DLL file was not found or could not be read. Check the command line.
Some dependent DLLs were not found or could not be read.
Some imports are missing from some dependent DLLs. If these are system DLLs, you are likely targeting a wrong version of Windows. If these are non-system DLLs, you need to install newer versions of them and all their dependencies.
1.: Apart from IESHIMS.DLL and WER.DLL which is apparently a bug in this old tool.2.: Or really, any problems in loading the DLLs on a particular system
The error description is misleading in this case. The system finds your DLL (project.dll) but one (or more) dependency of your DLL might be missing.
I just installed
Microsoft Visual C++ 2010 Redistributable Package
and now I can install the dll.
Although this works, I'm not too happy with this, because I don't want to have to install this package on a client in order for my dll to work by them.
I have Visual Studio 2010 installed and have a project I got from someone else which I can build successfully without any errors. I get a Wrapper.dll,
which I would like to access using JNA.
I am using Win7 64-bit.
But I get the error: java.lang.UnsatisfiedLinkError: Unable to load library 'Wrapper': The specified module could not be found.
Wrapper.dll of course is in the correct folder and it is a 32-bit dll and my Java program also uses a JRE with 32-bit, so this is not the cause of the error.
I used DependencyWalker to check whether *.dlls are missing:
MSVCP80.DLL
MSVCR80.DLL
GPSVC.DLL
IESHIMS.DLL
And yes there are some missing.
Can I conclude that the error is related with that these DLLs are missing?
But why does Visual Studio compile correctly then and does not throw an error?
How to solve this in order to access these functions in Wrapper.dll?
I also read that downloading dll's might not be the right thing to do!
(I know that Wrapper.dll relies on another dll or sourcecode which was built in Visual Studio 2005, if that is of interest.)
EDIT:
I found out, that Wrapper.dll relies on three other dlls which probably were built on MSVS2005. These require the above mentioned DLL's (checked with dependencywalker) and I guess therefore Wrapper.dll also links them.
So what do I actually do to get rid of these old dll's?
Would I need to build the other three DLLs with VS2010 or
is this a problem which always will appear, meaning, that you need to copy paste old DLLs in order to use the precompiled Libraries which are dependent on those.
Is there a way, that the program would run on any other system as well without copy pasting these DLL's?
All required DLLs must be available to the system for loading. If you define jna.library.path, that is where JNA will look for the initially loaded DLL, as well as any dependent DLLs. In addition, java.library.path (which is essentially PATH) will be searched for dependent DLLs.
MSVS often uses paths in addition to PATH when building, debugging, and running code within that environment.
Solutions:
a) remove dependencies you don't really need; this may include telling MSVS to build your DLL differently
b) include non-system DLLs next to your custom DLL (or include their location in PATH/java.library.path)
EDIT
a) you can include the offending DLLs in the same directory as yours. this is fairly low impact on the target system, but if they are DLLs that are expected to be on any system, you shouldn't have to do so. It's preferable to adjust java.library.path so that all system DLLs are accessible.
b) you can recompile your dependent DLLs and be more careful about backward compatibility and explicit linkage. Depending on features used by the DLLs, though, you may not be able to remove the dependencies.
MSVC[RP]80.DLL are C and C++ runtimes, respectively; you may or may not be able to link against a previous version.
IESHIMS.DLL is part of IE and should be on the system, but likely in a path inaccessible to your program.
GPSVC.DLL has to do with group security policy, so it should be available on the system (modulo whenever the DLL was introduced).
I developped a vb6 program then I build an installation wizard with visual studio interdev.
I used "dependency walker" and "process explorer" to find out the missing DLLs but there is always a problem with :
IESHIMS.DLL
WER.DLL
MPR.DLL
These dlls shown by dependency walker.
And when installing the program on another machine I have these error messages :
uxtheme.dll failed to register
msdatsrc.tlb failed to register etc..
PS : no problem on a machine where visual studio is installed.
Any Idea to fix this issue?
Thanks
Dependency Walker is not an appropriate tool to troubleshoot VB6 dependencies. It works well enough for DLLs written in C or C++ that use implicit dependencies. Although it hasn't kept up with the times and has trouble with DLLs that are stored in the Windows side-by-side cache or are delay loaded. Delay loading is what generates the warnings on ieshims.dll et al.
VB6 uses COM, which loads DLLs dynamically with LoadLibrary(). You'll never see such a dependency back in Depends unless you use the Profile option. Such DLLs are found back through the registry, the reason you needed to write an installer and tinker with regsvr32.exe.
You have to be pretty careful when writing installers like that, VB6 is old and can depend on operating system components that have been updated many times since 1998. Like uxtheme.dll, an important operating system DLL that implements visual styles. Having your installer overwrite the existing one on the user's machine is, well, disastrous. Although it is probably protected by Windows through its File System Protection feature, something that got added as a counter-measure against broken installers.
Giving proper advice is here difficult beyond "do no harm". A commercial installer like InstallShield or Wise (which I liked back then) is the best way to avoid shooting off the customer's leg. Fairly sure they still support VB6 installs. Microsoft makes a pre-cooked installer available for VB6 that installs all the core vb6 runtime components. You can download it here.
You should ALWAYS double check and verify any dependancies that you think your application needs.
All the files you mentioned are system DLLs and MUST NOT be distributed.
For a VB6 application you need the basic runtimes, and any DLLs you explicitly reference/use if and only if you have permission from the authors of those DLLs and instructions on the correct procedure and location for installing them.
For the standard Microsoft provided OCX files, these normally just need to be copied to the system32 folder and registered.
See redist.txt in the root of your Visual Studio installation for more details.
I would like to know when do we need to place a file under
C:\Windows\System32 or C:\Windows\SysWOW64, on a 64-bits windows system.
I had two DLL's, one for 32-bit, one for 64-bit.
Logically, I thought I'd place the 32-bit DLL under C:\Windows\System32, and the 64-bit DLL under C:\Windows\SysWOW64.
To my surprise, it's the other way around! The 32-bit one goes into C:\Windows\SysWOW64, and the 64-bit DLL goes into C:\Windows\System32.
Very confusing stuff. What's the reason behind this?
I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.
SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.
This article explains a bit:
Windows x64 has a directory System32 that contains 64-bit DLLs (sic!).
Thus native processes with a bitness of 64 find “their” DLLs where
they expect them: in the System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does
the magic of hiding the real System32 directory for 32-bit processes
and showing SysWOW64 under the name of System32.
If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.
I should add: You should not be putting your dll's into \system32\ anyway! Modify your code, modify your installer... find a home for your bits that is NOT anywhere under c:\windows\
For example, your installer puts your dlls into:
\program files\<your app dir>\
or
\program files\common files\<your app name>\
(Note: The way you actually do this is to use the environment var: %ProgramFiles% or
%ProgramFiles(x86)% to find where Program Files is.... you do not assume it is c:\program files\ ....)
and then sets a registry tag :
HKLM\software\<your app name>
-- dllLocation
The code that uses your dlls reads the registry, then dynamically links to the dlls in that location.
The above is the smart way to go.
You do not ever install your dlls, or third party dlls into \system32\ or \syswow64. If you have to statically load, you put your dlls in your exe dir (where they will be found). If you cannot predict the exe dir (e.g. some other exe is going to call your dll), you may have to put your dll dir into the search path (avoid this if at all poss!)
system32 and syswow64 are for Windows provided files... not for anyone elses files. The only reason folks got into the bad habit of putting stuff there is because it is always in the search path, and many apps/modules use static linking. (So, if you really get down to it, the real sin is static linking -- this is a sin in native code and managed code -- always always always dynamically link!)
Ran into the same issue and researched this for a few minutes.
I was taught to use Windows 3.1 and DOS, remember those days? Shortly after I worked with Macintosh computers strictly for some time, then began to sway back to Windows after buying a x64-bit machine.
There are actual reasons behind these changes (some would say historical significance), that are necessary for programmers to continue their work.
Most of the changes are mentioned above:
Program Files vs Program Files (x86)
In the beginning the 16/86bit files were written on, '86' Intel processors.
System32 really means System64 (on 64-bit Windows)
When developers first started working with Windows7, there were several compatibility issues where other applications where stored.
SysWOW64 really means SysWOW32
Essentially, in plain english, it means 'Windows on Windows within a 64-bit machine'. Each folder is indicating where the DLLs are located for applications it they wish to use them.
Here are two links with all the basic info you need:
MSDN File System Redirector
SysWow64 Explained
Hope this clears things up!
System32 is where Windows historically placed all 32bit DLLs, and System was for the 16bit DLLs. When microsoft created the 64 bit OS, everyone I know of expected the files to reside under System64, but Microsoft decided it made more sense to put 64bit files under System32. The only reasoning I have been able to find, is that they wanted everything that was 32bit to work in a 64bit Windows w/o having to change anything in the programs -- just recompile, and it's done. The way they solved this, so that 32bit applications could still run, was to create a 32bit windows subsystem called Windows32 On Windows64. As such, the acronym SysWOW64 was created for the System directory of the 32bit subsystem. The Sys is short for System, and WOW64 is short for Windows32OnWindows64.
Since windows 16 is already segregated from Windows 32, there was no need for a Windows 16 On Windows 64 equivalence. Within the 32bit subsystem, when a program goes to use files from the system32 directory, they actually get the files from the SysWOW64 directory. But the process is flawed.
It's a horrible design. And in my experience, I had to do a lot more changes for writing 64bit applications, that simply changing the System32 directory to read System64 would have been a very small change, and one that pre-compiler directives are intended to handle.
Other folks have already done a good job of explaining this ridiculus conundrum ... and I think Chris Hoffman did an even better job here: https://www.howtogeek.com/326509/whats-the-difference-between-the-system32-and-syswow64-folders-in-windows/
My two thoughts:
We all make stupid short-sighted mistakes in life. When Microsoft named their (at the time) Win32 DLL directory "System32", it made sense at the time ... they just didn't take into consideration what would happen if/when a 64-bit (or 128-bit) version of their OS got developed later - and the massive backward compatibility issue such a directory name would cause. Hindsight is always 20-20, so I can't really blame them (too much) for such a mistake. ...HOWEVER... When Microsoft did later develop their 64-bit operating system, even with the benefit of hindsight, why oh why would they make not only the exact same short-sighted mistake AGAIN but make it even worse by PURPOSEFULLY giving it such a misleading name?!? Shame on them!!! Why not AT LEAST actually name the directory "SysWin32OnWin64" to avoid confusion?!? And what happens when they eventually produce a 128-bit OS ... then where are they going to put their 32-bit, 64-bit, and 128-bit DLLs?!?
All of this logic still seems completely flawed to me. On 32-bit versions of Windows, System32 contains 32-bit DLLs; on 64-bit versions of Windows, System32 contains 64-bit DLLs ... so that developers wouldn't have to make code changes, correct? The problem with this logic is that those developers are either now making 64-bit apps needing 64-bit DLLs or they're making 32-bit apps needing 32-bit DLLs ... either way, aren't they still screwed? I mean, if they're still making a 32-bit app, for it to now run on a 64-bit Windows, they'll now need to make a code change to find/reference the same ol' 32-bit DLL they used before (now located in SysWOW64). Or, if they're working on a 64-bit app, they're going to need to re-write their old app for the new OS anyway ... so a recompile/rebuild was going to be needed anyway!!!
Microsoft just hurts me sometimes.