Kaja Fumei

My latest project involves dynamically importing from Windows DLL's on Unix. And guess what? It works. Sort of.

I built a unix program (in cygwin) in C that opens a DLL, load into memory (almost as Windows does), and you dynamically imports exported functions from the DLL. But since this is the second day on this project, there are limits. The Unix machine needs to support mmap() (but I could change that if I really wanted), and it needs to be a processor compatible with the one the DLL was compiled under (usually x86). And the biggest downside at the moment is that the DLL can't import any outside function (including standard c functions).

But what can it import? It can import functions from a DLL that have don't references to functions outside the DLL. You can, however, call other functions inside the DLL.

It has a long way to go before its really "practical" but the main goal is to eventually make a new "portable" dll/so format or just some way to make dll/so's portable to other systems.

It'll probably blow up in my face, but for now, I'm going to keep going

If anyone wants to test it out (hasn't been officialy tested on a real Unix machine) or view the source, let me know and I'll post it. Or if anyone wants me to try to make a Windows program to open an so, let me know.

tempest

I'd be interested in seeing the source code that you've created for it so far... sounds interesting.

__________________

coldDeath

I agree, that sounds interesting. How did you get the idea?

__________________

Kaja Fumei

Well, despite the best efforts of GNU, cross-platform programming (especially in C) is still a pain. And one of the biggest problems is libraries. I don't know how many times I wrote or copied a bunch of macros to call dlopen(), LoadLibrary(), etc. depending on the system. When the processor is the same/compatible, the only thing standing in the way of being portable to a different OS is the library's format and imported libraries (OS defined interrupts being different but there's not much you can do about that). Formats can be read and interpreted, no big deal. The real problem is when a DLL wants malloc, it's going to look for MSVCRT.dll no libc.so. Now I could probably import MSCVRT.dll if I wanted into it, that one would probably another DLL imported, and so on when you have a perfectly fine malloc in lib.so. Overcoming this is what I'm really trying to research and do.

Here's the source of opening a DLL in unix: http://www.entertheunknown.net/proje...pso_source.zip

I'm going to try importing ELF .so's into windows next to familiarize myself with the ELF format before deciding a plan of attack for importing.

Mad_guy

The main challenge you're going to face here (and the same challenge so many people before you have faced,) is getting the calls that .so files and .dll files make to work on the opposite systems well. Due to the nature of DLLs, there're a lot of tricks they can implement. For example, if you call HeapAlloc, what actually happens, is that HeapAlloc points to NtHeapAlloc, a native API call within the Windows NT kernel that is defined out of NTDLL.DLL in %WINDIR%\system32. Mapping the files is reletively easy given the memory mapping functions that things like Windows and Linux implment (such as MapViewOfFile and mmap) and you can just take parts of windows header files and stick them where you want and vice versa (which I see you have done well.) The main problem you're trying to resolve here is pretty simple: making it possible for all of those libraries to make calls that achieve the same result only on a completely different architecture. Windows is quite a complex system - Mutex's, handles, semaphores, critical sections, the native api, there are many things that play into the whole role of things. For example, if one function in a DLL resolves to returning a call from MapViewOfFile, chances are, if your linux program that calls that gets the return, it probably won't know what that return value is. You have done the easy part (that is, built a loader.) The hard part is still very much ahead of you and it is still very much going to be hard.


The only thing I can think of is having to make a heavy emulation layer, something like a linux kernel module that can detect and run dlls and such while resolving external dependencies. That's about all I can honestly think of. I wouldn't be expecting to recreate anything anytime soon though, WINE has been in development for something like a decade, and it's pretty far from perfect. A lot of people wonder why you can't just take linux apps over to windows and get them to work. Well, it's kinda like asking why can't you take an application compiled on Alpha over to x86 and have the program run properly on x86. Different architectures, different schematics, different ideology.


While that might have sounded kinda harsh, I must say that I do wish you luck on this. It will be quite interesting if you manage to make something like this work, and if all else fails, you can just write a wrapper to make linux .so files behave more like DLL files :>

__________________
os: mac os 10.5.4
revision control: git
editor: emacs

site

Kaja Fumei

I updated the source. A bunch of bug fixes, and improved ways of doing things. And imports work Anything imported into a DLL will automaticly be imported into the program. But there still is a problem: any Windows function that makes an OS system call/interrupt call will of course not work on linux (still works on windows). But it imported Windows' strlen without a problem.

Same address but I'll post it again: http://www.entertheunknown.net/proje...pso_source.zip

Mad_guy, this is just a stepping stone. I'm not trying to bring the Windows API to unix and I'm not trying to make another WINE. I would go crazy trying. The goal is to make a new format (call it pso) or possibly extend another one, so that I could import a library successfully on unix and windows if the same processor. Say I want to make, for example, a string library to be used as a module in my virtual machine. If I'm feeling lazy, the library will almost definitely make use of some string.h function; let's just say it's strlen. I want to be able say to windows to fetch msvcrt.dll for strlen and fetch libc.so on unix. Granted, this would take a lot more work than a new or extended format. At the very least, a whole new linker program. It's going to be a fair amount of work, but not the life commitment of trying something like WINE.