Is it possible to open a 16-bit Windows executable, just to browse its resources? I want to use LoadLibraryEx with LOAD_LIBRARY_AS_IMAGE_RESOURCE | LOAD_LIBRARY_AS_DATAFILE_EXCLUSIVE, so there is no worry about incompatibility with 64-bit processor, but it is still rejected, saying that it must be a valid Win32 executable. What was the function used to load 16-bit executables then?
16-bit NE images cannot be loaded nor (directly) executed by 32-bit or 64-bit PE threads. You have to load such a file using ReadFile() or similar and dissect yourself. Despite that RC files are mostly compatible, 16-bit resources are completely differently organized than 32-bit resources. Most notably, there is no language subdirectory level.
Related
I seem to be able to access the functions in C:\WINDOWS\system32\opengl32.dll (and likewise C:\WINDOWS\system32\glu32.dll) from either a 32-bit or a 64-bit application (for what it's worth, I'm doing this from separate 32-bit and 64-bit Python 2.7 interpreters, via the ctypes module).
With glut32.dll, things are different. It only happens to be on my Path as part of a 32-bit installation of GraphViz. From 32-bit Python, I can link dynamically to it, but from 64-bit Python I get [Error 193] %1 is not a valid Win32 application.
Now, this error does not surprise me, because I had always thought DLLs were obliged to commit to one architecture or another on Windows (in particular, this recent question and its answers seem to say so). What surprises me is the lack of an error in the first case... How does opengl32.dll do it, and how can I replicate this behaviour when building my own DLLs?
On 64 bit system only 64 bit processes use c:\Windows\System32\opengl32.dll. For 32 bit processes system redirects c:\Windows\System32\opengl32.dll to c:\Windows\SysWOW64\opengl32.dll.
File System Redirector
In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64. Access to %windir%\lastgood\system32 is redirected to %windir%\lastgood\SysWOW64. Access to %windir%\regedit.exe is redirected to %windir%\SysWOW64\regedit.exe.
Our application has up to now only used 32 bit binaries, it was enough.
Slowly we see the need to introduce 64bit versions (in addition to the 32 bit version) for some components, mostly for interfacing with other 64bit components that we didn't write ourselves.
One question that popped up was whether we want to name the 64bit components (EXE + DLLs) identically to their 32bit counterparts and put them in a another directory, or whether to name them differently (e.g. tool.exefor 32bit and tool64.exe for 64bit) and leave them in the same directory.
Microsoft has seemingly gone the route of different directories and identical names for most of the Windows components (WoW64), and if the whole application were 64 bit, we'd also have the case to just use the Program Files vs. the Program Files (x86) directory.
However, in our case we have a largely 32bit application that uses some 64bit components (executables) to do 64bit stuff and for some of these we also have a 32bit version that is also used.
So, do we rename components and put them in the same binary directory or do we keep the binary name the same and put it into a subdirectory?
What are the pros and cons?
If we're talking about a single application, all of its files should be kept in a single directory, per the bitiness. Meaning, either PF, or PF(x86). But not spread around.
Regarding components, ask yourself this.
Are these components used interchangeably, or do are they used in parallel?
If it's one the former, then have them the same name, this will simplify your deployment. But if it's possible that both are used at once, for example, a DLL that is used by both 32-bit process, and your 64-bit helper process, then split the names. Otherwise you will need to split up your directory structure.
Now I had to link to the 64 bit boost library DLLs.
Boost 64 bit DLLs have the same name as their 32 bit counterparts and there is no built-in way in Boost Build to change the output name, creating additional work if you would want them in the same directory.
Looking around, it seems that e.g. Qt doesn't include any platform or bitness tags in their DLL which would again generate problems if you would need 32bit and 64bit in the same directory.
So, it would seem that if you have 3rd party DLL dependencies in your application, and you need both the 32bit and 64bit application installed at the same time, then, no matter how you name the executable (or your DLL) itself, putting them into different directories seems a good idea because then it's easy to work with 3rd party stuff that doesn't "tag" its DLLs with the bitness, because there really isn't a good way of loading different DLLs with the same name from the same directory (unless you put them into System32 / SysWOW64, which you shouldn't).
I am having a problem with windows system function “EnumProcessModules()” that is defined in psapi.dll. In our component we use this function to retrieve modules in a specified process. This function is working well as long as we run the program on a 32-bit OS. However, this function fails when we run the program on a 64-bit OS (e.g. W2K8 R2). As you all know we are targeting Clay and Brick on W2K8 R2s. This is a known problem as per the following discussion in MSDN. One work around that was suggested in that thread is to compile the code as 64-bit. To us that is not an option, at least not yet. Do you have any suggestions? Any pointers/suggestions/ideas will be appreciated.
http://social.msdn.microsoft.com/forums/en-US/winserver2008appcompatabilityandcertification/thread/c7d7e3fe-f8e5-49c3-a16f-8e3dec5e8cf8/
If your existing code must continue being compiled as 32-bit, one possibility would be to create a small 64-bit executable that enumerates the processes via EnumProcessModulesEx. The 32-bit process could spawn the 64-bit process when necessary to do that work. Then use some kind of IPC to transfer the information back to the 32-bit process. Depending on what is needed, that part could be as low tech as writing a file to disk and reading it from the first process (or pipes, shared memory, sockets, etc.).
So a .exe file is a file that can be executed by windows, but what exactly does it contain? Assembly language that's processor specific? Or some sort of intermediate statement that's recognized by windows which turns it into assembly for a specific processor? What exactly does windows do with the file when it "executes" it?
MSDN has an article "An In-Depth Look into the Win32 Portable Executable File Format" that describes the structure of an executable file.
Basically, a .exe contains several blobs of data and instructions on how they should be loaded into memory. Some of these sections happen to contain machine code that can be executed (other sections contain program data, resources, relocation information, import information, etc.)
I suggest you get a copy of Windows Internals for a full description of what happens when you run an exe.
For a native executable, the machine code is platform specific. The .exe's header indicates what platform the .exe is for.
When running a native .exe the following happens (grossly simplified):
A process object is created.
The exe file is read into that process's memory. Different sections of the .exe (code, data, etc.) are mapped in separately and given different permissions (code is execute, data is read/write, constants are read-only).
Relocations occur in the .exe (addresses get patched if the .exe was not loaded at its preferred address.)
The import table is walked and dependent DLL's are loaded.
DLL's are mapped in a similar method to .exe's, with relocations occuring and their dependent DLL's being loaded. Imported functions from DLL's are resolved.
The process starts execution at an initial stub in NTDLL.
The initial loader stub runs the entry points for each DLL, and then jumps to the entry point of the .exe.
Managed executables contain MSIL (Microsoft Intermediate Language) and may be compiled so they can target any CPU that the CLR supports. I am not that familiar with the inner workings of the CLR loader (what native code initially runs to boot strap the CLR and start interpreting the MSIL) - perhaps someone else can elaborate on that.
I can tell you what the first two bytes in .exe files contain - 'MZ'. i mean the characters 'MZ'.
It actually represents: Mark Zbikowski. The guy who designed the exe file format.
http://en.wikipedia.org/wiki/Mark_Zbikowski
1's and 0's!
This wikipedia link will give you all the info you need on the Portable Executable format used for Windows applications.
An EXE file is really a type of file known as a Portable Executable. It contains binary data, which can be read by the processor and executed (essentially x86 instructions.) There's also a lot of header data and other miscellaneous content. The actual executable code is located in a section called .text, and is stored as machine instructions (processor specific). This code (as well as other parts of the .EXE) are put into memory, and the CPU is sent to it, where it starts executing. (Note that there's much more interfaces actually happening; this is a simplified explanation).
I remember a few years ago(2002) there was a multipartite virus that could be run natively on linux and windows. I don't know if a compiler could be specially craft an executable so that it could be read as both ELF and PE, so that the os would start executing at different entry points. Or a program that could merge two programs, one compiled using mingw, one compiled in native linux, to one program.
I don't know if such a program exists, or could it exist, and I'm know this could be implemented in Java or some scripting language, but that's not a native program.
Imagine the possibilities, I could deploy a program with linux and window (and perhaps os/x)libraries, and one main executable that could be run on any os. The cross-platform support would compensate the bigger size.
Windows programs have a DOS stub in the beginning, and I just ran an ELF executable through debug.com, which said that the first instruction of this exe was JG 0x147. Just maybe something could be done with this...
No.
Windows and Linux use vastly different binary file formats. See Portable Executable (Windows) and Executable and Linkable Format (Linux).
Something like WINE will run Windows executables on Linux but that's not the same thing.
This is actually a really terrible idea for multiple reasons.
Cross-compiling across operating system boundaries is extremely difficult to do properly.
If you go for the second route (building separate PE binaries on Windows and ELF on Linux, and then somehow merging them) you have to maintain two machines, each running a different OS and the full build stack, and you'd have to make sure that you tested both versions separately before gluing them together.
Dynamic linking is already a pain to properly manage, on Windows and on Linux; static linking can generate binaries that are much more inconvenient to deal with than whatever imaginary benefits you get from providing one single file type to your end-user.
If you want to run the same binary executable file on multiple OSes, your options are Java, Mono, and potentially NativeClient, the browser plug-in Google's developing to work around the "webapps are too slow" problem.