Slashdot Mirror
Wine In New Skins
Thanks to Jeremy White of Codeweavers for sending over some of the previews of Wine 1.0. I had a chance to see this during ALS, and was very impressed by what they are doing. 1.0 has Gnome/KDE integration, as well as new (better) config program, and some new launcher features. As well as doing this, they've also WineHQ, for all the Wine news that you can drink.
LinuxONE lite, at least in theory, does this. I haven't been able to connect to their webserver lately, though, so I couldn't tell you what the status of that is, nor can I download and test it.
WARNING: there is a trojan on your
Regarding preventing the development of Linux apps, there is evidence to the contrary. For instance, Word Perfect has been ported to Linux, yet the Free office projects are stronger than ever. Also, Wine is supporting more Windows games than ever. Meanwhile, Loki keeps cranking out native ports.
Regarding performance, there is no reason why Windows would perform inherently better. Wine Is Not an Emulator. It is a native unix implementation of the Windows API's, which basically amounts to a set of libraries and a glorified linker.
Winelib means that initial porting can be as simple as a recompile.
Users are ecaping from their Windows environment. If I use 99 applications on my Linux box which are native to Linux, and 1 that is native to windows, I'd say I've successfully escaped the Windows environment. Legacy support does not mean you're trapped in the legacy environment. On the contrary, it's a powerful tool to free you of that environment while not losing access to a specific application.Historically, lack of applications, or lack of one specific application on Linux has been a major obstacle preventing people from becoming full-time Linux users. Once Wine can reliably run most Windows applications, the barrier against change becomes much smaller. And, as the user becomes more familiar with Linux, apps mature and are ported, the legacy Windows applications used under Wine can be phased out.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
As far as I can recall, wine can be configured to access parallel and serial ports. Other emulators, like VMWare can do the same. And, might I add, for running programs that don't use ActiveX type stuff, VMWare is a lot better than wine, but you need a copy of Windows installed on the computer.
I don't know about how to get a win32 bin to access linux hardware, but have you considered using perl? Perl has modules for accessing serial and parallel ports, and you can pick a UI of your choice (everything from (n)curses to Gtk to Tk to wxWindows to ...). Perl works on win32 and *nix (and pretty much anything else with a power cord, I'm expexting a perl-driven toaster Real Soon Now).
Plus, it doesn't suck like VB.
There are of course other ways to do this (C anyone?), the other scripting language people are likely to mention is python, which is a perfectly vaid choice as well and may be more preferable to somebody with an OO background (or pseudo-OO like VB). I _think_ there are comm port APIs for python (that's just comparatively simple C code after all, and one thing all the *nix-originating scripting langs seem to be great at is glomming around C code (perl, tcl, python, et al)).
--
News for Geeks in Austin, TX
Umm... Why? And how exactly do you plan to make the developers of Wine stop working on a program they want to work on? Emulated software never beats native software. No matter how good the emulation gets, there's always going to be some advantage to running native software. Remember - when OS/2 was released, it ran Win3.1 binaries at least as well as Windows itself. Yet there were still quite a lot of OS/2 native programs released. (And there still are a surprising amount, for a "dead" OS)
Oh, and BTW, many members of the "linux community" develop software not because there's a demand for it, but because they need something done that current software doesn't quite fulfill. If Windows software filled that need, they'd presumably be using Windows. But they aren't, which should tell you something. Many are out to write good software, not take over the world.
-RickHunter
First, get the cygnus (now owned by RedHat) toolkit . This gives you a great many unix type commands (tar, ls, cp, dd, less, cat, pwd, ftp, cut, sort, etc), and a real bash shell, and a decent terminal window. Just having the bash autocompletion and command line history is worth the price of download, not to mention your directory slashes now go the right way
Next, get yourself the activestate perl port for windows. This gives you perl, which combined with the cygnus toolset makes easy and highly portable scripts very easy to throw together.
Next, get the putty secure shell tools . This gives you pscp (like rcp, but better in every regard) and a pssh (a secure telnet replacement). These will both connect right up with a RedHat 7 system running the openSSH stuff right out of the box.
Of course, get the latest version of emacs for windows.
Finally, just for good measure, throw on Apache so you can serve up files in a pinch. This is handy in case you need to move files around with a system that lacks secure shell for whatever reason. Just throw together a quickie page and use browsers to do all the transfers.
I keep all these tools on a single burned CD (with room to spare). They are the first things I put on any system I use. With this toolset, windows goes from a useless development platform to a slightly annoying development platform, which is better then nothing when your clients require windows on your desktop box.
Mathematically impossible requirements are technically not against policy.
I have StarCraft running to include battlenet. The way I had to do this was to make a small winers partition (about a gig) install everything there StartCraft, BroodWar, patch it all. Then boot into Linux and run it from there. It works fine for me. I could never get it to work without putting it on a winders partion though. This works fine for me because of damn dialpad.com (they save me almost $300 a month and for that I will let my machine be dual booted for now. Now if I could get the dialpad applet to run under Linux I'd start working on getting rid of the winders partition.
Cypherpunks: Civil Liberty Through Complex Mathematics. Those who live by the sword die by the arrow.
"And no one puts new wine into old wineskins; if he does, the wine will burst the skins, and the wine is lost, and so are the skins; but new wine is for fresh skins." Mark 2:22
I have discovered a truly marvelous sig, unfortunately the sig limit is too small to contain i
Hmmm... Well, I can't think of anything much easier than downloading and installing ZipSlack or BigSlack. Both of these distros are UMSDOS-native, which means that their whole filesystems live as a file in an existing FAT16 or FAT32 partition.
They're great for novices, since the default installations will run with a minimum of tweaking.
Of course, that's not what you wanted: while it would be cool to have a little Linux box running in a window on your Windows Me (yuck!) machine, this seems to me to be a task much more satisfyingly accomplished by simply using Windows to telnet in to the real thing.
I run Windows 95B on my main machine at home and at work, mostly because I need the Windows applications. I run Windows 95B specifically because it includes FAT32 support, it has a better 16 bit subsystem than its successors, and I don't have to put up with crap like the Active Desktop and other later "enhancements". I barely trust Windows as it is, let alone trying to operate a full virtual machine inside it.
However, an X client for Windows would be great, so that the connection to the real Linux box could also be graphical. That way, I could use my Linux server for other stuff without having to move the nice monitor from my main system.
And yeah, I know telnet is insecure, but I like it both on my home and work LANs. (Neither one of which includes people who would be capable of rooting a box.) I haven't looked around for this, but has anyone seen a telnet client for Windows 9x that will provide pretty colors like RedHat's directory listings or so that I can actually use Lynx?
Fire and Meat. Yummy.
Extra-X! can do this.
If you're interested in helping, contact me or him at karrde at callisto.yi.org.
Jeff
Why is the official Wine logo (a wine glass) not used here? The current windows icon is just horrible!
A quick look to recent headlines shows that slashdot is using the offical logos for Gnome, KDE, Apache and more. So why not Wine?
====
Codeala - Just another mindless drone
If Wine 1.0 is available (Thanks to the Wine Team!) wont this accelerate the development and deployment of M$'s ".NET" cra^H^H^Hstuff?
I believe M$ is very actively creating a moving target - sure you'll be able to emulate Office2000, but what happens when Office".NET" is 'un-emulate-able" simply because it lives somewhere else and runs through your browser?
Running Linux to emulate 'old' Windows Software becomes a little less attractive than The New Exciting! M$".NET" stuff...
That is the key to understanding how Wine can work with Linux in a cooperative manner. Linux users can use Windows programs under a stable, free operating system. If it works out, then why would anybody buy Windows any more? Linux would be able to run all off-the-shelf software, albiet written to Win32. Take that situation and fast forward it 5 or 10 years and what do we have? Linux applications being written for Linux. Look at the 68k software for MacOS when the PowerMac came out. By your arguments, nobody would have written PowerMac software because 68k software worked "just fine" on all the machines; the same thing is happening right now with Cocoa and Carbonized applications. The truth is, development happens on the most predominate platform -- having Wine helps Linux garner more platforms, and the logical result is that free UNIX wins in the end (Wine runs on more than just Linux).
OS/2 is a red herring in this argument; back then there were 2 competing standards tyring to woo DOS users. People had to pay more for OS/2 with Windows 3.11; when they could buy the "real thing" from Microsoft for less. Now, in the current situatio which one costs less?
The wheel is turning but the hamster is dead.
The wheel is turning, but the hamster is dead.
Anyone want to start a project that allows Windows machines to run Linux binaries? With the way it's going, that's what Windows will need to be a desktop OS.
If tits were wings it'd be flying around.
"Wine Is Not An Emulator" can be screamed and shouted every day, all day. The fact is people use it as such. As is Linux users run Quick books on Linux+Wine without Intuit having expended a single coin to port it over. For all practical purposes we have Quick books on Linux now. There is no longer much of a financial incentive for a Linux port.
Yes and no. It's a question of the market dynamics, and in the short term, you're probably right. Intuit can ride on Wine for a while. (Of course, since they've shown no interest in Linux, that's better than nothing!) However, the same argument could have been made for why nobody would ever write Win32 applications for Windows 95, when 16-bit applications would run perfectly well (with no need for porting) and there was already a very large base of Windows 3.11 users to contend with.
In the end, Windows 95 never would have been accepted without the 16-bit compatibility; the installed base was too critical. In fact, that's the only reason Windows 95 was created -- Windows NT wasn't taking the market by storm, and Microsoft realized they needed a stepping stone to get people using 32-bit applications. That much has worked; 32-bit applications are now the norm.
Linux could well follow a similar path as Windows 95 did. First, you need compatibility with existing applications. Since Linux can be had for free, people are encouraged to try it. Since it's more stable and more powerful, people may stick with it. When the compatibility with Windows 95 is near-perfect, there will be no need to keep Windows around any longer. Once the needs of the mainstream users are met, the majority may move to Linux, as they once moved to Windows 95.
If that happens, the mass of the market would start demanding quality native applications that would run better under Linux than emulated Windows applications, much as they demanded higher-quality Win32 applications. Yes, native Linux applications would lock out Windows-only users; companies would maintain two ports if both markets are large enough to be worthwhile, or possibly just the Linux one if it somehow had the majority marketshare by then. (With good Windows 95 compatibility, it could happen -- Microsoft has had trouble getting people to upgrade when they consider Windows 95 good enough for their needs already.)
There's no guarantee that this will happen, but it's certainly possible. (It would certainly take years, if it happens at all.)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
I use Wine daily. More accurately I use it constantly. For programs written by friends who don't have Linux. It has it's teeting troubles, it's still cranky in places but it's a life saver (life expectancy of anyone in the same room as me when I am forced into windows is measured in minutes). All progress on Wine is good news.
This has made my day!
FP.
Also FatPhil on SoylentNews, id 863
It may run in windows... however, there is no version of VMWare that I see for windows 95/98! That leaves a good deal of us out of the water.. *sigh*
The long term effect of Wine on Linux is still open to debate. One logic to follow is that developers like to write as little code as possible to reach the desired audience.
This is why many Unix developers code to POSIX and ignore the special tweaks available on even the most popular of commercial Unix systems. "Write once, Run anywhere" wasn't invented by Sun's Java Marketing team.
That brings us to OS/2 with it's robust ( at the time ) Win16 support. Developers were faced with a choice. Write apps for OS/2 and enjoy patronage of the OS/2 userbase or write for the Win16 API and enjoy the Windows 3.11 userbase AND the OS/2 userbase.
That wasn't a tough call and OS/2 was driven from the desktop in part because of it.
"Wine Is Not An Emulator" can be screamed and shouted every day, all day. The fact is people use it as such. As is Linux users run Quick books on Linux+Wine without Intuit having expended a single coin to port it over. For all practical purposes we have Quick books on Linux now. There is no longer much of a financial incentive for a Linux port.
Fast forward a bit to the next version of Quick Books. It has made use of some special new feature in the Windows 64 API of Whistler and it will take years of hacking for Wine to support it again. Suddenly the Linux, QB users are left out in the cold.
This is why the Wine Runtime is may be a bad thing. The porting API is however a different animal. It works well enough to get an app over but for long term development; you really need to rewrite in KDElibs or something like that to work properly on a Linux desktop. Maintaining a Wine port must be a nightmare by comparison.
At least it shows signs of going to 1.0 Something that all software should do at least once in it's life. That still leaves the Hurd as the code base determined to NEVER be "finished". Of course they have a different problem. Linux delivers to the user what Hurd intended but with a different technology. V6, V8 ? Who cares, I want Miles Per Galon and cruising speed.
--= Isn't it surprising how badly I spell ?
Part of the point of Wine, IMHO, is to help Linux hit that "critical mass" at which point it can start competing with Windows on equal terms. And that is undeniably a Good Thing(tm).
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
You mean an X *server*. My favorite is XWin32, which has had no significant problems with any of the apps I run.
Windows programs have the same permissions as the user running WINE. If the user running WINE has access to the serial port, so does the WINE app. You need but to put something like the following in your wine.conf:
[serialports]
Com1=/dev/ttyS0
Com2=/dev/ttyS1
Com3=/dev/modem,38400
Com4=/dev/modem
Now, if you need actual raw access, that's available too (though of course appropriate permissions are required). In your wine.conf, just put something like the following:
[ports]
read=0x779,0x379,0x280-0x2a0
write=0x779,0x379,0x280-0x2a0
Hopefully, though, the character devices will suffice.
Comment removed based on user account deletion
Anti-Slashdot-Effect Mirror:
1 .0 -preview/
http://turbogeek.org/anti-slashdot-effect/wine-
I'm pretty sure Underage Linking is still a crime......
Also there is a D2 specifically for linux, you just copy a few files from the CD on over, and there is Kali for linux. Worked fine for me awhile back.
Not sure about that battle.net though.
Anyone who's used Visual Basic knows that while the language is a pus-filled zit on the nose of all programmers, it is really easy to access hardware directly using controls such as MSCOMM32.OCX, et al...even on WinNT/2k.
I used such a program to control a couple of serial barcode scanners. I'd love to be able to do this on Linux - anyone know if Windows programs are allowed to access the hardware under WINE?
Is this rock and roll, or a form of state control?
Wine will expand Linux-use customer base.
1) More ppl begin to use Linux because they can use familiar apps on it.
2) Once familiar with Linux, large scale software-buyers get Linux software, phasing out emulated software
3) People have Windoze-blinders on. emulation the best way to gradually remove the blinders through retraining
Goat sex free since 2001