Slashdot Mirror

You are correct.

A significant part of the wine development is on winelib, which allows windows applications to be compiled on linux, bsd or pretty much any unix for i386. There is also work on porting winelib to sparc systems.

RTFM people WineLib Users Guide

I fail to see how this capability would take any support away from porting applications.

1. Install a Windows app under Windows, and it populates the 'Start' button.

   Install a Windows app under Plex86, VMWare, Win4Lin and each time you want to use that app you have to switch to another window or turn on the other operating system just to have the chance to click that damn Start button.

To me, it's no big deal...but to a few non-geeks I've talked to as well as a few Uber-geeks, it's the only concern; is it exactly like running the same app under Windows?

It can be. The good folks at Codeweavers are working on a user interface that automatically populates the KDE and Gnome menus, allowing novices to install thier own software. Very slick -- and a critical safety blanket that can tempt the novices over to Linux let alone to other *NIX.

At this point, the pre-release is available for download but Wine itself isn't yet a 1.0 release...so many apps might be easy to use if they can be installed.

1. Install a Windows app under Windows, and it populates the 'Start' button.

   Install a Windows app under Plex86, VMWare, Win4Lin and each time you want to use that app you have to switch to another window or turn on the other operating system just to have the chance to click that damn Start button.

To me, it's no big deal...but to a few non-geeks I've talked to as well as a few Uber-geeks, it's the only concern; is it exactly like running the same app under Windows?

It can be. The good folks at Codeweavers are working on a user interface that automatically populates the KDE and Gnome menus, allowing novices to install thier own software. Very slick -- and a critical safety blanket that can tempt the novices over to Linux let alone to other *NIX.

At this point, the pre-release is available for download but Wine itself isn't yet a 1.0 release...so many apps might be easy to use if they can be installed.

Take a look at the prototype of the new documentation page here.

Take a look at the items at the bottom of the Wine 1.0 todo list here.

Take a look at the plans for revamping the apps database here. BTW, we need help. Wanna quit complaining and give us a hand?

However, I do have to agree in one important point - many Wine users have a tendency to get an app up, and then that gets reported to Slashdot. But, the reality is, it doesn't work well, so everyone stampedes to try Wine, and gets disappointed. The key thing we're trying to get to with the new apps db is *honest* and verifiable app reports.

Take a look at the prototype of the new documentation page here.

Take a look at the items at the bottom of the Wine 1.0 todo list here.

Take a look at the plans for revamping the apps database here. BTW, we need help. Wanna quit complaining and give us a hand?

However, I do have to agree in one important point - many Wine users have a tendency to get an app up, and then that gets reported to Slashdot. But, the reality is, it doesn't work well, so everyone stampedes to try Wine, and gets disappointed. The key thing we're trying to get to with the new apps db is *honest* and verifiable app reports.

For example, there is now an easy to use configurator for the .winerc file. While it's not committed to CVS (yet), you can download winecfg here.

We're working on getting most installers working under Wine; for a lot of installers, you can do the following:

1. wine setupxxx.exe (answer the questions)
2. Click on the icon on your desktop
   (assuming the app installed an icon to the desktop).
3. app runs.

4. You can see more of the overall Wine 1.0 status at http:/wine.codeweavers.com/status.shtml

For example, there is now an easy to use configurator for the .winerc file. While it's not committed to CVS (yet), you can download winecfg here.

We're working on getting most installers working under Wine; for a lot of installers, you can do the following:

1. wine setupxxx.exe (answer the questions)
2. Click on the icon on your desktop
   (assuming the app installed an icon to the desktop).
3. app runs.

4. You can see more of the overall Wine 1.0 status at http:/wine.codeweavers.com/status.shtml

The guy who wrote TWIN is no longer with Willows (which is actually a subsidiary of Caldera) because they decided they didn't want to pay to maintain the thing anymore. He's moved to CodeWeavers, and has merged the code with WINE to create Twine.

The guy who wrote TWIN is no longer with Willows (which is actually a subsidiary of Caldera) because they decided they didn't want to pay to maintain the thing anymore. He's moved to CodeWeavers, and has merged the code with WINE to create Twine.

The major difference between MainWin and this being CygWin is open source.

No, the major difference between MainWin and Cygwin is that they go in opposite directions; MainWin provides a Win32 API atop UNIX-compatible OSes, while Cygwin provides a UNIX API atop Win32 OSes. If you want to contrast Cygwin to a non-open-source UNIX-apps-atop-Windows product, contrast it with Interix, and if you want to contrast MainWin with open-source Windows-apps-atop-UNIX software, contrast it with Wine or TWIN or Twine, say.

1. However, Wine has been used primarily for binary emulation. It's Winelib source porting toolkit has often been neglected and lags behind the source porting facilities in TWIN.
   
2. Also, Wine has little or no provision for cross platform support. It really only targets x86 Linux machines well.

Later in the FAQ:

1. Although the Twine project is an open source project, with limited CVS write access, we ask all Twine developers to never modify Wine code within Twine. Instead, we prefer that all work on Wine modules be done directly within the confines of the Wine project. That way, any efforts we make within Twine are immediately shared with the Wine project, and no licenses are violated.
   
2. Further, CodeWeavers is retaining all rights to new code written for use in Twine. This means that we will be able to release that code under the Wine license.
   

More fundamentally, in terms of the broad Linux movement, wouldn't it make more sense for the majority of us Linux C++ programmers to focus our efforts on creating/finishing a completely OpenSource tool which could port the Win32 API's and the MFC to Linux compatible source code?