Question on exposing non-windows functions from dlls...
I just submitted a patch to wine-patches that provides the implementation of spawnl and spawnlp. I had been hoping to implement execl and execlp as well but found that the underlying functionality that I would need is not exposed outside scheduler/process.c. My question is what guidelines are there, if any, are there to exposing non-win functions, such as exec_wine_binary in scheduler/process.c? Also, from just a cursory glance at exec_wine_binary that I may need to wrap it to do some of the work that fork_and_exec and PROCESS_Create are doing, such as calling DOSFS_GetFullName. I'm not sure what, if anything, the server would need to know about this. -- TTFN MikeB
On Fri, 18 May 2001, Mike Bond wrote:
I just submitted a patch to wine-patches that provides the implementation of spawnl and spawnlp. I had been hoping to implement execl and execlp as well but found that the underlying functionality that I would need is not exposed outside scheduler/process.c. My question is what guidelines are there, if any, are there to exposing non-win functions, such as exec_wine_binary in scheduler/process.c?
The guidelines are pretty simple and easy to understand: with a very few *very* exceptional exceptions, never ever expose them. And definitely never to non-core DLLs such as msvcrt - there's no reason an application DLL like msvcrt can't be implemented on top of the Win32 API the same way it's implemented on Windows.
On Fri, May 18, 2001 at 06:59:12PM +0200, Ove Kaaven wrote:
On Fri, 18 May 2001, Mike Bond wrote:
I just submitted a patch to wine-patches that provides the implementation of spawnl and spawnlp. I had been hoping to implement execl and execlp as well but found that the underlying functionality that I would need is not exposed outside scheduler/process.c. My question is what guidelines are there, if any, are there to exposing non-win functions, such as exec_wine_binary in scheduler/process.c?
The guidelines are pretty simple and easy to understand: with a very few *very* exceptional exceptions, never ever expose them. And definitely never to non-core DLLs such as msvcrt - there's no reason an application DLL like msvcrt can't be implemented on top of the Win32 API the same way it's implemented on Windows.
If you can point me to some way of implementing _exec[lv][ep] using the standard win32 API I would be more than willing to. Unfortunately that was one arguable shortcoming of win32 process management in that it did not have any interface that allowed loading and running an image in-process. -- TTFN MikeB
On Fri, 18 May 2001, Mike Bond wrote:
If you can point me to some way of implementing _exec[lv][ep] using the standard win32 API I would be more than willing to.
You could do: if (CreateProcess(...) == successful) ExitProcess(...);
Unfortunately that was one arguable shortcoming of win32 process management in that it did not have any interface that allowed loading and running an image in-process.
No, but who says that that's what exec does in msvcrt anyway? It would be a big mistake to accuse Microsoft implementations of having the same semantics as similarly-named Unix functions, so don't do that, please.
On Fri, May 18, 2001 at 06:59:12PM +0200, Ove Kaaven wrote:
The guidelines are pretty simple and easy to understand: with a very few *very* exceptional exceptions, never ever expose them. And definitely never to non-core DLLs such as msvcrt - there's no reason an application DLL like msvcrt can't be implemented on top of the Win32 API the same way it's implemented on Windows.
I have gone ahead and implemented most of the exec variants as described just terminating the previous process, the internal spawn implementation already provided a flag to accomplish this easily. On the question of determining compatibility, what methods are we "allowed" to persue? For instance, I created a small test app for the exec variants, tested it under Windows NT then under Wine. I would hope this is a valid method, but with the way the lawyers work, it's sometimes hard to tell. As a note, it seems NT is doing the same thing as they end up with different address spaces and pids after execl. -- TTFN MikeB
Mike Bond wrote:
On the question of determining compatibility, what methods are we "allowed" to persue? For instance, I created a small test app for the exec variants, tested it under Windows NT then under Wine. I would hope this is a valid method, but with the way the lawyers work, it's sometimes hard to tell.
Big disclaimer: I am not a lawyer; if you end up in court because you pay attention to anything I say, that's just too darn bad. It depends on which country you're in. What you've done is classic "black box" reverse engineering, which has historically been protected by the U.S. legal system. Even the DMCA protects it as long as you don't decrypt anything. UCITA in its unaltered form, however, legitimizes all those software license agreements that U.S. courts have found unenforceable. So I guess it's starting to depends on what state you're in if you're in the U.S. -- ======================================================================== Ian Pilcher ian.pilcher(a)home.com ========================================================================
participants (3)
-
Ian Pilcher -
Mike Bond -
Ove Kaaven