Forgive my newbness. I'm pretty fresh to Linux, but trying to port some reasonably sizable 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 bits an pieces, basically just to get my orientation sorted. One of my apps is an internet client/server jobbie, Currently it's targetted 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, 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. I'm not sure what I'm supposed to be doing. [Shocked] 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. 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 :)
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.
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. With respect to the console app, I can try (although it may we a worthless excercise) 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 comand line statement.
Dan Kegel wrote:> On Tue, Apr 15, 2008 at 3:49 PM, AndyA <wineforum-user at winehq.org> 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? > - DanWhy 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'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 wrote:> No worries. Just trying to help you avoid some common pitfalls. > As long as you're happy, I'm happy. > - DanI'm happy as long as I know why I'm doing what I am.
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.
Ove Kaaven wrote:> 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.
whoops, to list! ---------- Forwarded message ---------- From: David Gerard <dgerard at gmail.com> Date: 16 Apr 2008 17:50 Subject: Re: [Wine] Winelibs question..... To: Ove Kaaven <ovek at arcticnet.no> On 16/04/2008, Ove Kaaven <ovek at arcticnet.no> 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 wrote:> On 16/04/2008, AndyA <wineforum-user at winehq.org> 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 wrote:> > AndyA wrote: > > 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!