Slashdot Mirror
Programming With WineLib
paulydavis writes "The
c/c++ users journal has an article about porting windows applications to Linux using
Winelib. The article is a good tutorial on how to obtain winelib and how to use such things as the winebuild and the winemaker tool."
Why not just avoid the Win32 APIs and use a cross-plpatform framework like wxWindows? You can built native Windows, Linux/Unix, and Mac GUI applications from the same source code. It's also been around for about 11 years.
cpeterso
that's a fine approach for 'new' applications, but this is a much faster approach for porting existing apps or using existing API skillsets.
It's pretty cool that something like this exists, especially for big existing codebases, but I so wish there was a nice modern cross platform windowing template library.
Sure would make a nice addition to boost.
I just love to spend the whole day watching bootscreens!
it _so_ more productive than watching my favorite soapopera
- I choked on the red pill and now I'm stuck in limbo
So when can we expect the finished Linux port of Laser Squad Nemesis? I used to love the original Amiga version on my old A500, and am dying to get this on my Linux box.
What I really need is to run kids' software (Reader Rabbit, Putt-Putt Goes to the Moon, etc) without forcing the kid to start Wine first. Could this library Linux to recognize the binary as a Windows executable and run it through dynamic linking? Or is it only useful for porting the code?
For geek dads: Contraction Timer
Its only usefully for porting software. You can create links and icons for each of your software - this works but takes some setup on your part. Or alternatively you can use vmware. (Win4Lin doesn't support DirectX very well). I haven't played with WineX - but that may also be a solution.
There is a Wine daemon that can run and intercept a call from the shell or filemanager and make the appropriate wine calls invisible to the user. RedHat 8 has it on by default when you choose to install Wine. It is quite useful, because a binary is now a binary, no matter what is required to run it, the appropriate libraries and environment are automatically loaded.
-- the computer doesn't want any beer, no matter how much you think it does. NEVER, EVER feed your computer beer.
It is quite useful, because a binary is now a binary, no matter what is required
Isn't there a teensy bit of a virus issue with doing something like this to a Linux box? Seems like it would be well worth the time to manually create shortcuts that launch Wine rather than just let any Windows code run unchecked.
It's this kind of thing that got Windows in trouble with viruses in the first place.
The line must be drawn here. This far. No further.
Didn't this already happen? There was a story about somebody's Linux machine successfully propagating a Windows email virus, due to a Linux email program automatically (or maybe manually) executing a program attached to an email. The Windows executable was recognized and loaded the Wine libs and ran. The virus failed to infect the machine but it did succeed in opening the users address list (maybe a Windows address list on a mounted Windows drive) and emailing itself to everybody on the list.
You've been able to do this for quite some time now by using the /proc filesystem. Check out this mailing list post for details:
http://www.winehq.com/hypermail/wine-devel/2002/06 /0044.html
I know of no such daemon, and one wouldn't really be very useful. Making Linux able to execute Windows EXEs "natively" in this way is little more than a semantic change - all it does is run "wine foo.exe" for you when you write "./foo.exe" - neat, but... what's the point?
Especially when you consider that mostly wine apps will install to the fake C drive
Isn't there a teensy bit of a virus issue with doing something like this to a Linux box?
Not in the kids' account with no network privileges and no write privileges outside of /home and /tmp.
Will I retire or break 10K?
For that matter, just running linux applications unchecked would be just as dangerous. We should have a confirmation screen that makes sure you intend to be using /bin/ls and not /usr/bin/ls or /usr/local/bin/ls.
Running code is dangerous. Your account privs must be in place. It doesn't matter if the app needed winelibs or not.
There are no trails. There are no trees out here.