Winelibs question.....

[AndyA]

Forgive my newbness. I'm pretty fresh to Linux, but trying to port some reasonably seizable windows apps that I have written. Certainly my gui apps appear to work directly with wine. I also have stuff that makes more sense to use with winelibs.

I've had no significant difficulties setting up and compiling small bits an pieces (hello world type stuff), basically just to get my orientation sorted. The real work is one of my apps. Its an internet client/server jobbie, Currently it's targeted to IIS on Windows 2003/2008, using ISAPI.

I'm looking to move it to Linux so that I can host it on a remote dedicated server, along with other stuff which is likely to work better with Linux. I have the ISAPI angle covered because I have an internet services library with a common base which can either be ISAPI or CGI. Clearly I'm going to be using Apache on linux.

There are three components the server, the "net stub", and a remote client app. The net stub uses windows pipes, to communicate data from the server to the web browser through the webserver. The client app communicates directly with the server via sockets. The server is currently a windows service.

My first question is fairly general, and goes to anyone with some experience of porting apps using Wine. Is it likely that the "net stub" and server components will work as reliably (or at all) on Wine(libs) as they do on Win32. Requires support would be things like interprocess communication using named pipes, interthread communication using windows message queues, mutexes, file io and sockets.

I suspect that wine will make a reasonable stab at that, and I appreciate that this is a bit of a difficult deal to answer, but perhaps pragmatic feedback on similar successes/failures would be appreciated.

O.K. In the mean time, a more detailed query;

In the interest of keeping things simple I decided to create a simple app in windowsland, all it does is create a file, and store a number in it. Each time you run the app, it reads the file, increments the number and stores it back out to disk. The aim was to get this to run using winelibs. Obviously the calls are all Win32 API or standard C.

It's working fine on windows, so to the port.

Things went well to the point of linkage. Winemaker seems a dream, but I was surprised to receive a ".so" from the build. More reading revealed that a "spec file" would be required, primarily to resolve the entrypoint, but also to deal with LoadLibrary, and exports if I were attempting to produce a "runtime linked" library. O.K. so I'm not trying to do the latter.

I assume, although it's not *that* clear to me that the product of the excercise is a straight elf binary that I can run from a prompt.

I'm not sure what I'm supposed to be doing. :)

Perhaps I am supposed to be linking directly with the ".so" (created from the original winemaker parse/make process) at run time, in a new elf binary that I have yet to create.

Perhaps I am supposed to be linking again statically with the previously produced "coff" (I assume they're coff) objects and ignore the produced ".so".

Perhaps I have a choice? I'd prefer he latter, I go to a great deal of effort usually, to avoid big binaries, and DLL's.

Either way I'm a bit confused because "winebuild" does not seem to accept a "spec" file, as stated in the documentation. I can piece together what I need to do with "winebuild" from the man pages, and it seems to produce a c source file that, on inspection, seems to make sense. (as some kind of stub?)

Unfortunately if I try to compile it, the compiler reports;

winegcc -c -mno-cygwin -I. -o WineLibTestSpec.o WineLibTestSpec.c
winegcc: gcc-3.4 failed
make: *** [WineLibTestSpec.o] Error 2

as a result of;

WineLibTestSpec.c:
$(WINEBUILD) -fPIC -o WineLibTestSpec.c --exe --entry=main

WineLibTestSpec.o: WineLibTestSpec.c
$(CC) -c $(CFLAGS) $(CEXTRA) $(DEFINCL) -o WineLibTestSpec.o WineLibTestSpec.c

in the make file.

There isnt too much information coming back from the compiler, and I'm not sure where to go next. Does anyone have any suggestions?

Sorry for the long post.

TIA

[Dan Kegel]

Why not just run your apps with Wine? There really isn't that much benefit
to using Winelib unless you're planning on radically changing the UI.

[AndyA]

Well that's just it. For the time being the gui part of the deal is not a problem, I can run that with wine (normal) and I have no problems.

The significant benefit of wine(libs) to me, is that I can be called from Linux and call into Win32, with my "net stub" (CGI binary). The linux call is the entrypoint and the Win32 calls are back to the server.

With respect to the console component (a GUI app), I can try (although it may be a worthless exercise) to get the sockets part working with straight wine. I could even test it with the server on my windows box.

The trouble is that the server and net stub components need to be on the Linux box.

The server component currently runs as a service on windows, although for debug purposes, I can run it from the command line without the windows service manager. That too then would be a candidate for direct usage with normal wine, and would probably work.

The trouble really is the net stub. With that, since it is a CGI binary, it is called possibly as many as a thousand times for each loaded html page. I cant expect to load and dispose of wine each and every time the CGI binary is loaded.

Now I've said that I'm wondering exactly how the wine "binary" might work, but I feel reasonably confident that if the server is already running then loading wine will not be a problem.

What will likely be a problem is making the call from, say, apache. I'd imagine that the CGI spec only caters for the loading of a named binary, and not executing a command line statement.

[AndyA]

O.K, well some further inspection reveals that it's the wine install that is the problem. The guidance would still be very welcome, maybe I could write something up, when I get it working?

[Dan Kegel]

On Tue, Apr 15, 2008 at 3:49 PM, AndyA <[email protected]> wrote:

The trouble really is the net stub. With that, since it is a CGI binary,
it is called possibly as many as a thousand times for each loaded html page.
I cant expect to load and dispose of wine each and every time the CGI binary is loaded.

That may be so, but it has no bearing on whether you use wine or winelib.

If you want efficiency, you should not be using CGI, which runs
a binary for each and every HTTP fetch. This would be a problem
even with native binaries, let alone winelib/wine binaries.

I'm afraid I don't understand what you mean by the CGI binary
getting called a thousand times for each loaded page. That
seems excessive. How is your server architected?
- Dan

[AndyA]

On Tue, Apr 15, 2008 at 3:49 PM, AndyA <[email protected]> wrote:

The trouble really is the net stub. With that, since it is a CGI binary,
it is called possibly as many as a thousand times for each loaded html page.
I cant expect to load and dispose of wine each and every time the CGI binary is loaded.

That may be so, but it has no bearing on whether you use wine or winelib.

If you want efficiency, you should not be using CGI, which runs
a binary for each and every HTTP fetch. This would be a problem
even with native binaries, let alone winelib/wine binaries.

I'm afraid I don't understand what you mean by the CGI binary
getting called a thousand times for each loaded page. That
seems excessive. How is your server architected?
- Dan

Why does the intricate detail of how my server is architected matter to you? I've explained enough already, and you seem to have missed the obvious point. With that I have said already I'm sure your critique doesn't need my input.

I'm trying to build with winelibs. If you tell me what *your* problem is, I might be able to help you with it.

I'm not particulary concerned about efficiency, as it happens..... And I know that leads to perl or someone else's solution. Maybe I could buy your software?

I suppose I could try out FastCGI, but where I'm at, at the moment, it wouldn't be a benefit to me, whereas compiling against wine would.

I have a whole pile of prerequisites, that have already lead me to the choice that I have currently made. When there is a practical reason not to do it this way I'll stop, and go a different way. I appreciate that I am the worst programmer in the world, but TBH, it's not an unreasonable question.

I mean, if it makes you happy, forget the server stuff, and just pretend that I asked a question about a silly little app that increments a number in a file!!! I'm only doing it because I'd like to be able to!

I'm not here to avoid a problem. I'm here to try and solve one.

It's allright if you don't have the answers, you know.

[Dan Kegel]

No worries. Just trying to help you avoid some common pitfalls.
As long as you're happy, I'm happy.
- Dan

[AndyA]

No worries. Just trying to help you avoid some common pitfalls.
As long as you're happy, I'm happy.
- Dan

I'm happy as long as I know why I'm doing what I am.

(And it still counts, when I know why, I don't know what I'm doing!)

[Ove Kaaven]

AndyA skrev:

I assume, athough it's not *that* clear to me that the product of the excersise is a straight elf binary that I can run from a prompt.

Actually, you're supposed to end up with a .so, which Wine can load
after bootstrapping. Then your application launcher is either a symlink
to Wine itself (after booting, Wine will look at how it's invoked and
look for a .so of the same name in the same directory), or it can be the
wineapploader shell script. The winelib executables that come with Wine,
such as winecfg, use wineapploader. Or you can simply invoke your
Winelib executables by typing "wine appname", where appname is the name
of your .so file.

As for reliability, I've seen someone claim to use Wine to run
mission-critical web services because it crashes less often than
Windows, so there's hope.

[AndyA]

AndyA skrev:

I assume, athough it's not *that* clear to me that the product of the excersise is a straight elf binary that I can run from a prompt.

Actually, you're supposed to end up with a .so, which Wine can load
after bootstrapping. Then your application launcher is either a symlink
to Wine itself (after booting, Wine will look at how it's invoked and
look for a .so of the same name in the same directory), or it can be the
wineapploader shell script. The winelib executables that come with Wine,
such as winecfg, use wineapploader. Or you can simply invoke your
Winelib executables by typing "wine appname", where appname is the name
of your .so file.

As for reliability, I've seen someone claim to use Wine to run
mission-critical web services because it crashes less often than
Windows, so there's hope.

After playing some more last night I was beginning to come to the conclusion that you are suggesting here. Thanks for the input.

Strangely this is all quite sweet with ISAPI because the binary is loaded by the webserver and retained in the application pool. Much better approach. As I understand it, that's what FastCGI does too, but it's not been around long enough for me to develop any support for it. The last thing I really need at the moment is a greater number of unknowns.

The primary motivation behind the port to Linux is PhpBB (the cost alone wasn't enough). The trouble with Windows Server there is that database support for Windows 2008 is still pretty lame.

I had PhpBB3 working with Vista, IIS7 and SQLExpress. One night it stopped working (SQLExpress). After quite a bit of swearing I've now come to the conclusion that the only way I'm going to get it to work again is to reinstall Windows.

On the Windws Platform (Vista+) at the moment the only sensible option is MSSQL, and I want to be using something else, so that I don't have to be thinking about reinstalling OS's on remote machines.

So if I want to use MySQL, I guess Linux is my best bet. Another possibility is server virtualisation, but even that gets expensive, really quickly.

When push comes to shove, all I want is a setup that's cheap, I can fix remotely, and doesn't need fixing too often. (Just the world then)Optimisations I can sort later.

[David Gerard]

whoops, to list!

---------- Forwarded message ----------
From: David Gerard <[email protected]>
Date: 16 Apr 2008 17:50
Subject: Re: [Wine] Winelibs question.....
To: Ove Kaaven <[email protected]>


On 16/04/2008, Ove Kaaven <[email protected]> wrote:

As for reliability, I've seen someone claim to use Wine to run
mission-critical web services because it crashes less often than Windows, so
there's hope.

We use Wine at work to run a Windows console binary from a dead
company (so no prospect of porting or updates). It runs on a Linux box
with a zillion other things, rather than a Windows box, where it would
have to be pretty much the only thing running and cost us a Windows
licence and the PC to run it on - so for us it's not reliability, it's
sort-of-virtualisation. It's run flawlessly for years. It's the
example I bring up whenever anyone claims Wine will never be ready for
real-world use



- d.

[David Gerard]

On 16/04/2008, AndyA <[email protected]> wrote:

So if I want to use MySQL, I guess Linux is my best bet. Another possibility is server virtualisation, but even that gets expensive, really quickly.

I may have missed something, but what's wrong with MySQL for Windows
in this use?


- d.

[AndyA]

On 16/04/2008, AndyA <[email protected]> wrote:

So if I want to use MySQL, I guess Linux is my best bet. Another possibility is server virtualisation, but even that gets expensive, really quickly.

I may have missed something, but what's wrong with MySQL for Windows
in this use?
- d.

No, you might have a point there. Maybe it would work better with Vista using cygwin.

TBH I'm sick of all the products that really don't work very well. I think it's why I'm a bit miffed that winelibs don't seem to want to produce a binary that will execute from a prompt.

For me, my last experience with Unix was back in the early Nineties. All those neat simple features, just seem to have gone. Replaced by a thick layer of confusion and needless complication.

I've been digging today, and what I'm trying to work out at the moment is why "ld" won't easly be coaxed into producing a working absolute executable. I remember a platform somewhere in time, where it was difficult to get ld to produce anything but!

Seems fine through gcc, but if you invoke it separately, it's a different thing. I suspect that gcc is producing format specific "lumps" for the linker, and I think it would take me some convincing to think that it's the right approach.

Obviously I'm well off my target track now, and linux is at the point for me, where I just put up with buying Windows Server 2003, and possibly migrating to a more usable version of Windows as 2008 matures. I doubt anyone would believe me if I was to suggest that it's not my preferred route!!

[vitamin]

I've been digging today, and what I'm trying to work out at the moment is why "ld" won't easly be coaxed into producing a working absolute executable.
[snipped all irrelevant]

Because Wine is not a simple library that just can be linked to.

[Dan Kegel]

On Wed, Apr 16, 2008 at 1:59 PM, AndyA <[email protected]> wrote:

TBH I'm sick of all the products that really don't work very well. I think it's why I'm a bit miffed that winelibs don't seem to want to produce a binary that will execute from a prompt.

For me, my last experience with Unix was back in the early Nineties. All those neat simple features, just seem to have gone. Replaced by a thick layer of confusion and needless complication.

I've been digging today, and what I'm trying to work out at the moment is why "ld" won't easly be coaxed into producing a working absolute executable. I remember a platform somewhere in time, where it was difficult to get ld to produce anything but!

IIRC, the big reason is that win32 code requires a different memory
map than that usually offered by Linux. We address that with a
preloader that sets up the needed memory map, then loads
glibc and the winelib app.

Now, if that preloader were integrated a bit more into the system,
it wouldn't seem so alien. But there hasn't been much incentive
for anyone to change the core system simply to accomodate wine.
Perhaps once Wine can run 50% of Windows apps flawlessly,
we can agitate for it...

Until then (and perhaps not even then), wine (aka winelib) will *not*
be simply a library you can link in to your linux apps. It's not
a simple thing to make win32 apps run on unix.
- Dan

[AndyA]

I've been digging today, and what I'm trying to work out at the moment is why "ld" won't easly be coaxed into producing a working absolute executable.
[snipped all irrelevant]

Because Wine is not a simple library that just can be linked to.

Mmm, I'm sure that might sound like Wine is great, and I'm stupid. That's not where I'm coming from at all. I have no gripe against Wine, or the good people that develop and support it.

What I'm talking about is GNU ld!

I'm actually a bit sad that you see me talking down Wine, or that other people might interpret it that way. Perhaps that alone says more than anything else.

[vitamin]

I've been digging today, and what I'm trying to work out at the moment is why "ld" won't easly be coaxed into producing a working absolute executable.
[snipped all irrelevant]

Because Wine is not a simple library that just can be linked to.

Mmm, I'm sure that might sound like Wine is great, and I'm stupid. That's not where I'm coming from at all. I have no gripe against Wine, or the good people that develop and support it.

What I'm talking about is GNU ld!

Read what I said again. You can not _link_ to Wine. Wine is not a library. It can not be loaded after that fact of starting main executable. Wine have to be running first. Regardless how you do it. If you want to "run" .exe files - use binfmt for that.

[AndyA]

Because Wine is not a simple library that just can be linked to.

Mmm, I'm sure that might sound like Wine is great, and I'm stupid. That's not where I'm coming from at all. I have no gripe against Wine, or the good people that develop and support it.

What I'm talking about is GNU ld!

Read what I said again. You can not _link_ to Wine. Wine is not a library. It can not be loaded after that fact of starting main executable. Wine have to be running first. Regardless how you do it. If you want to "run" .exe files - use binfmt for that.

And what I'm saying to you is that I'm not trying to!


!!!DONT PANIC!!!

FWIW, I stopped trying to do that about eight hours ago, so that I could try and get a better feeling for the way static and dynamic linking works on Linux.

I'm more than happy to accept that I need to learn some stuff here, but I really do get the feeling that you want to hear that.

Over and out.

[Dan Kegel]

On Wed, Apr 16, 2008 at 2:11 PM, AndyA <[email protected]> wrote:

What I'm talking about is GNU ld!

ld is not the problem. As we've been trying to tell you, wine is not
a library you can link to.