Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Porting Windows Dynamic Link Libraries to Linux

github.com

Post reply on HN
Print view View original

31–40 of 44 posts

Re: Porting Windows Dynamic Link Libraries to Linux

#31

Post by omgtehlion »

reacweb wrote: post #30
psykotic wrote: post #10

This reminds me of a tool Jeff Roberts wrote at RAD Game Tools which would repackage libraries so they were loadable on Linux. At the time the motivation was that MSVC was generating much better code than GCC for Bink, so he'd compile on Windows with MSVC and cross-link to Linux with his custom tool.

Does MSVC still generate better code than GCC ? I do not find any recent benchmark.

Generally, no. But you should benchmark your own code.

In my experience, some code paths are better optimized by cl.exe, some by gcc. Overall difference is negligible though.

Re: Porting Windows Dynamic Link Libraries to Linux

#32

Post by SA500 »

tathougies wrote: post #6

Why not just use full-on WINE? The basic system calls are pretty much fully covered. It seems this duplicates a lot of work.

'This project does not replace Wine or Winelib.

Winelib is used to port Windows C++ projects to Linux, and Wine is intended to run full Windows applications. This project is intended to allow native Linux code to load simple Windows DLLs.

The closest analogy would be ndiswrapper but for userspace.'

Re: Porting Windows Dynamic Link Libraries to Linux

#33

Post by mariuolo »

badminton1 wrote: post #24

I don't know if I would like software ported to Linux in this way. I already have mixed feelings about WINE. My concern is really on the legal side of things. What if these things are patent protected and people start getting sued?

Do you realise this is a debugging tool?

Re: Porting Windows Dynamic Link Libraries to Linux

#34

Post by IshKebab »

bonzini wrote: post #28
pierrec wrote: post #19

This is cool and a lot lighter than WINE, though the important keyword is self-contained Windows libraries. I gather this won't work on DLLs that call any of the plethora of Windows APIs. I'm actually very surprised that any non-trivial DLLs are self-contained in this way, like his example of Windows Defender which I thought would call 1000 Windows API functions.

A bunch of C runtime library and Windows APIs are implemented or stubbed: * https://github.com/taviso/loadlibrary/tree/master/peloader/w... * https://github.com/taviso/loadlibrary/blob/master/peloader/c...

Like... in Wine? (Yes I read the readme)

Re: Porting Windows Dynamic Link Libraries to Linux

#35

Post by hexmiles »

I read the readme, but i still can't understand how is different than winelib (and i don't know much of ndiswrapper internal).

I understand that since is a debugging oriented tool has a different scope than wine, but why don't use (at least partially) the already implemented windows function? I am missing something? maybe this is more efficient o maybe wine is not enough modular?

Re: Porting Windows Dynamic Link Libraries to Linux

#36

Post by ConfucianNardin »

hexmiles wrote: post #35

I read the readme, but i still can't understand how is different than winelib (and i don't know much of ndiswrapper internal). I understand that since is a debugging oriented tool has a different scope than wine, but why don't use (at least partially) the already implemented windows function? I am missing something? maybe this is more efficient o maybe wine is not enough modular?

Winelib requires you to (re-)compile from source.

This project allows you to load (some) windows DLLs as-is.

Re: Porting Windows Dynamic Link Libraries to Linux

#37

Post by alnitak »

adrianpike wrote: post #4
gadnium79 wrote: post #2

why?

...why not?

While I agree the grandparent's comment doesn't add much to the conversation, and even has many obvious answers, why is a more interesting question. You are basically questioning if there is a need to change the status quo, or put in physics terms, why do you want to expend energy to move from the local stable point? What is the point with higher stability you want to reach, and what are the characteristics that make this point desirable and justify the energy expenditure?

Re: Porting Windows Dynamic Link Libraries to Linux

#38

Post by jackmott »

reacweb wrote: post #30
psykotic wrote: post #10

This reminds me of a tool Jeff Roberts wrote at RAD Game Tools which would repackage libraries so they were loadable on Linux. At the time the motivation was that MSVC was generating much better code than GCC for Bink, so he'd compile on Windows with MSVC and cross-link to Linux with his custom tool.

Does MSVC still generate better code than GCC ? I do not find any recent benchmark.

it's never been true in general but still happens sometimes.

Re: Porting Windows Dynamic Link Libraries to Linux

#39

Post by rwj »

kazinator wrote: post #14

Did this close to twenty years ago. Ported a COM DLL to Linux and one of the executables using it. I implemented everything it needed. COM functions like CoCreateInstance, entry points like DllCanUnloadNow, Windows Sockets and whatnot. The registry API! Ha. I mapped HKEY_CURRENT_USER to configuration files rooted in the user's home directory, and HKEY_LOCAL_MACHINE to /etc. The lib's DllRegisterServer nicely register…

Same thing here. Wrote enough of a COM implementation that some software could be compiled native on Linux. The cool bit was that we automatically generated the Python bindings as well, so all the COM components were easily accessible for scripting.

Re: Porting Windows Dynamic Link Libraries to Linux

#40

Post by mirimir »

analognoise wrote: post #9
adrianpike wrote: post #4

Earlier quoted context omitted.

...why not?

I've always thought why is more important than why not. Example: "I'm going to hit myself in the dick with a hammer."

Actually, that's not so problematic unless there's an anvil involved, or the hammer is moving quickly.
Post reply on HN