wine users - Mar 2007 - Problems creating a winelib-based program

Fleabag <madparrott@gmail.com> wrote:
> As a proof of concept, I have started small. I wrote a simple Windows
> DLL with an exported function which returns a string, and built it on
> my Windows PC. I wrote a OS X program (source code is in
> "simpleapp.cpp") which loads the DLL (using LoadLibrary), locates
the
> function (using GetProcAddress), calls the function and displays the
> string to stdout.
I do not quite understand. If this program uses the Win32 API and will
be compiled using winelib, why do you call it an "OS X program"?
> I used winemaker to generate the Makefile, then built it using make.
> This automatically linked the executable with winelib. The result is a
> file called "simpleapp.exe.so". It does execute and function as
> expected, BUT, unfortunately cannot be run standalone, it seems it
> *has* to be launched using "wine simpleapp.exe.so". If I try to
run
> simply "./simpleapp.exe.so" then I get the message "Bad
program (or
> shared library)".
As I see it, you want a library and not a standalone executable. What
happens if you tell your application to use simpleapp.exe.so as a
plugin?

Daniel

Please note: my questions and problems are arising using winelib on
Intel Mac OS x, *BUT* they are so generic that any UNIX user who knows
winelib should in principle be able to answer, hopefully...

First, here is the background to what I am trying to achieve:

1) As a PC user, I bought a commercial Windows program which accepts
third-party plugins written as Windows DLLs.
2) I am now an Apple Mac (Intel) user and have the Mac OS X version of
the same commercial program, which accepts third-party plugins written
as shared libraries ("bundles", if you care).
3) I have a number of Windows DLL plugins I bought for the Windows
version of the commercial program, which are NOT available in the Mac
shared library form.
4) I want to write a shared library plugin which wraps a Windows DLL
plugin, so that the commercial program can load it and not be able to
tell it has been duped!
>From 4) I hope you can understand that, since the code will be built as
a shared object library to be loaded by the commercial application, it
cannot be launched using "wine progname" since the commercial program
cannot be told to do so. The shared object library must therefore
launch any required wine stuff (wineserver and X11 perhaps?) when it is
first loaded.


As a proof of concept, I have started small. I wrote a simple Windows
DLL with an exported function which returns a string, and built it on
my Windows PC. I wrote a OS X program (source code is in
"simpleapp.cpp") which loads the DLL (using LoadLibrary), locates the
function (using GetProcAddress), calls the function and displays the
string to stdout.

I used winemaker to generate the Makefile, then built it using make.
This automatically linked the executable with winelib. The result is a
file called "simpleapp.exe.so". It does execute and function as
expected, BUT, unfortunately cannot be run standalone, it seems it
*has* to be launched using "wine simpleapp.exe.so". If I try to run
simply "./simpleapp.exe.so" then I get the message "Bad program
(or
shared library)".

Returning to my ultimate goal, this is not a workable solution because
there will be no opportunity to explicitly call wine. I was hoping that
the point of winelib was that one could develop UNIX (or OS X in my
case) applications which can be run normally and which can call Windows
functionality through winelib when required?

Is my understanding flawed?

Is there any way to provide my application with a normal startup stub
which allows the operating system to run it as a normal program,
without calling the "wine" program, and then internally have some call
or other which starts up whatever wine infrastructure is required (like
wineserver perhaps, and X11?) at the point that it is required eg when
my code finally loads the Windows DLL?

Thanks in advance for any help anyone can offer me... :-)


Fleabag