Having used Wine for a lot of late '90s / early '00s Windows games, I think Win32-on-Wine is possibly the best, most stable game platform in history. Modern laptops run games of this era without breaking a sweat, publishers couldn't assume users had the bandwidth to patch everything after release, so there's a playable game right there on the CD. Many CD-ROM games didn't bother with copy protection (after all, who would copy a whole CD full of data?), so you can play straight from an iso.
> publishers couldn't assume users had the bandwidth to patch everything after release, so there's a playable game right there on the CD
A reminder that Daggerfall (aka Buggerfall, aka the game that had a game-breaking bug in the very first dungeon at the beginning of the map) shipped in 1996.
Their most recent game is an example of what happens when they remove the mod community. A lot of people were very upset with FO76, but it being MMO disallowed mods, so game breaking bugs existed weeks into the game's release.
I was super surprised my university pirated PuTTY. I knew it because I saw the "PuTTY keygen" app on the desktop. Only years later I realized it's an app for generating ssh keys...
True. Fortunately by now there are cracks for most of those games. And those cracks are relatively simple by modern standards. Maybe a few hex edits and/or a replacement DLL.
I realize it's a bit different, but have you considered something like the NES, in terms of "what's the most stable platform?"
NES emulators have been ported to basically everything, which in turn makes NES games playable anywhere. And this includes modern NES games as well, as long as they were tested against either super-accurate emulators or real hardware (to ensure no reliance on specific emulator quirks).
Or sad. As a user and developer, 98% of the differences between these operating systems don't really matter to me at all. They only exist because of historical accident, desire for proprietary lock-out, or other pointless reasons like ego. For anyone who didn't believe it, they've finally gone and given a proof by construction.
We've abstracted over the CPU nicely. Without even thinking about it, my software will compile and run on any modern CPU just fine. Excellent! But it's dumb that we still have to learn about the specifics of the OS, just to write a simple application. I wish they'd just pick some kernel-level API, some common formats (filesystem, executables), some UI-level APIs, etc., and then everyone could just write to that.
(That's basically what the web is, except the API is in terms of HTML/CSS/JS, rather than CPU/RAM/disk/devices. You know you suck at standardization when you're getting lapped by the web standards committees. It's easier for me to cross-compile C to JS than to compile C on all the different platforms I use. What happened?)
It seems like every couple decades, a few companies get together to try to make a standard operating system (Multics, Taligent), and it always falls apart. We're just about due for another doomed effort!
This assumes that there is agreement on what the UI experience should be. Navigation patterns, menu bars, keyboard shortcuts, touch gestures.. But there is still active competition between OS vendors on UI.
Just in the last decade, the most common form of interaction with a computer has changed from mouse and keyboard to touch and speech recognition.
> It's easier for me to cross-compile C to JS than to compile C on all the different platforms I use. What happened?
The web is a lowest common denominator. A web app is still missing a lot of affordances that users take for granted in a native app on their given OS. That is why still in 2019, there are new native iOS and Android apps being developed. Look, there are even entirely new programming languages being invented (Swift) or integrated (Kotlin) for the purpose of writing native apps for those platforms.
Specifically regarding compile C, I don't see what your problem is compiling C. You can even compile C11 on windows with Clang.
Yes you may choose to include a OS-specific header and it won't compile, but also your JS doesn't necessarily run if you call some browser specific function.
Yes, it is, but why? HTML/JS has a LCD interface. x86 has a LCD interface. Even filesystems sort of have an LCD (some superset of MS-DOS FAT). Shouldn't the OS have one, too?
If we standardized filesystems, executables, and syscalls, I don't see how our world would be any worse, and I can think of many in which it would be better.
If you write standard compliant C, don't use platform specific headers, and use some kind of cross-platform build system (I can't recommend CMake enough here), it's easy to use C/C++ across platforms. UI/graphics is harder, but cross-platform solutions do exist here (Qt, GTK, WxWidgets, OpenGL).
The biggest issue with CMake is how many libraries seem to have really low quality CMakeLists.txt's.
CMake is very easy to use, if you do things properly with targets. include_directories and link_libraries should never never ever be used, use target_include_directories and target_link_libraries instead. This way there is no need to mess about with shell script style variables for dependencies. But so many resources online explain to people how to do things the wrong way, and so their libs end up being a pain to build or depend on.
If your using stuff like MSYS2 does cmake/meson have a big advantage over old make/autoconf? I thought cross platform was the biggest selling point for these tools.
For me, sanity is the main selling point. Make has meaningful space/tab distinction - that's quite enough to disqualify it as hopelessly mad in my book. And then autoconf is just baroque.
CMake only helps a little bit (it's still very old and has way too many warts). But Meson is very pleasant to work with.
I wouldn't argue that we should be happy about how the web turned out.
It always feels like computers are stuck in the same place because every time we improve CPU performance, we end up adding more layers of abstraction so the whole thing is moot.
No, I definitely don't want one OS, or one UI or experience. I want one interface. We've already got architectural similarity between operating systems. The part that's different is the interfaces between them, for completely arbitrary reasons.
We've done this for layers below the OS (x86) and layers above it (HTML, JS). There's just this one layer in the middle which we missed.
Funny I was just wondering if you could run Wine on the Linux subsystem for Windows and run Windows apps in that environment. A complete waste of time and energy so little chance I will try.
It may be funny but it may be a way to support certain older games/applications that don't run well on Windows 10. For example in order to run Dracula 3 on Windows 10 one has to use the Wine implementation of Direct3D:
https://fdossena.com/?p=wined3d/index.frag
I've actually tried to run HeidiSQL through Wine on Windows and I succeeded.
The tricky part was the X11 server. X.org doesn't seem to work on the Linux subsystem, but there are a few X11 servers for Windows. If you install one of them, you can run Linux GUI programs.
Xorg works in WSL, it just doesn't have any backing graphics driver to actually render anything. But if you install XRDP, you can connect to your Linux desktop using the usual Windows remote desktop client.
But yes, there are better options. You can run Xming or other X server and configure it yourself. Or you can buy X410 in the app store, and then the only configuration needed is DISPLAY=:0 in your shell.
Testing across multiple .net frameworks without containers or virtual machines.
It's a lot faster to initiate an app inside wine on Linux then start up a VM and launch it on Windows. I think it's even faster than containers on Windows but don't have any data to back it up.
Lastly, for sandboxing applications (not a great security layer of course, but safer than running natively) so they don't pollute the registry or access sensitive files.
Wondering if it's possible to play dx12 games on older versions of Windows that don't officially support it.
Funnily enough, there was an article about malware doing exactly this for AV evasion some time last year. Existing behavioral analysis wouldn't be effective since they were looking at Linux syscalls.
> Microsoft's plan to invade cuba and overthrow the government has succeeded. One Microsoft official said "It's a win-win situation. The US Government is happy and shuts up the DOJ while Microsoft institutes a monopoly within Cuba for everything from computer software to toilet paper. One more step closer to world domination. Heck, we could feed a whole development department for the cost of one developer's salary in the US. They may not know how to create an Operating System very well, but neither do our US developers."
Oh my. I wasn't sure what I was looking at and then I read that to the right of the link.
It takes an incredibly talented developer or team thereof to build such a reimplementation. I wonder how much talent has been wasted chasing competitors' implementations in this way. That's talent that could have been spent improving the state of the art, given a different history. Ah, well.
to me this just proves that linux has won. (no this is not about the year of the linux desktop). for as long as wine exists we have been looking for ways to run windows software on linux, but now microsoft is trying to run linux software on windows.
quite obviously linux has something that they want.
I've been a fulltime Linux user for 15+ years, and up until last year I avoided using Wine (because I didn't require it -- I didn't need any Windows tools, and I wasn't a gamer).
On my last holiday break I wanted to install and play a few games, which included using Wine to play Windows games. I was pleasantly surprised at how well it worked. Out of the ~10 games from GOG that I installed, all of them worked.
I wish there were a more user-friendly way for people to use it, without the command-line and winetricks. I use wine on macOS, but I usually hesitate before diving in, because I know it inevitably involves some gymnastics. Even with Wineskin Winery (which is no longer maintained?).
Will WINE ever be at a point where it would be stable enough to make the case for non-technical users? Another comment joked about public offices -- would it be absurd to think offices could run linux instead of windows, saving licensing costs, using WINE where legacy software is necessary?
I would have started using WINE even earlier if the documentation were more approachable. I think they've improved over the last few years, though the site still looks like an antique forum system rather than cutting-edge tech + design, like you would see from a startup's website.
Valve has been doing a lot of work here lately, they've essentially made Wine into a first party citizen of Steam (in the form of Proton). So Wine is stable & easy enough for non-tech users - at least for gaming purposes. But there isn't the equivalent for general software yet.
That said, I was attempting to run a Proton game a few weeks back and it kept failing silently. Running from the terminal revealed a missing dependency, which I apt-getted and now it works fine. So while I agree that Proton is fantastic, there's still some work to be done in making it more friendly for "non-tech" users.
Is it not the case that if you use the steam runtime then libraries should be there? Ultimately valve are targeting steamOS not linux as a whole. Some linux distros (eg arch) have a package that bundles the steam runtime which should make such issues go away.
Steam runtime doesn't have every lib ever made, can collide with libraries in the system, and game devs might not include some dependencies because of licenses without notice. I think GP had the latter case.
Lutris is a popular Wine prefix manager. There is also PlayOnLinux.
> Will WINE ever be at a point where it would be stable enough to make the case for non-technical users?
On Linux - yes, on macOS - not likely, given the waning interest of Wine developers in doing it for macOS, thanks to Apple's sabotage of OpenGL, Vulkan and 32-bit support there.
> Will WINE ever be at a point where it would be stable enough to make the case for non-technical users?
IMO for everyday use it pretty much already is.
Example: I installed MS Office 2010 using the official MS office installer, in a specially isolated Wine environment using a somewhat cumbersome command-line. This is expert-stuff, I agree, but what follows is not.
After the installer had completed Wine had picked up the application installations inside Windows and made them available (through wine) in my regular Linux application launcher with nice icons and everything.
I didn't lift a finger, and now I could use MS Word like any native Linux app anywhere in Gnome, even associate it with DOCX-files in Nautilus.
Call me easily impressed, but I found that above and beyond what I expected wine to do for me.
I wrote an app to do this on Mac several years ago, then abandoned it for lack of users. Crossover from CodeWeavers is a great GUI wrapper, but it's not free.
PlayOnMac is fairly user-friendly, relatively speaking. You do still have to interact with winetricks via a GUI, but I've been able to achieve everything I've wanted without ever using a CLI. Worth trying if you haven't, it's quite a lot smoother of an experience than Wineskin Winery.
Sure, there's Lutris or Steam's Proton to help with that. I wanted to try out Magic the Gathering Arena a few weeks ago. All I had to do was install Lutris, and that automatically set up Wine configs, installed dependencies, and even downloaded and installed the game.
I've found WineBottler on Mac to be fairly easy to use... you use it to install your program then it creates a standalone Mac executable which runs it in future
I guess it involves some freedesktop.org stuff so I'm not sure what happens in Mac OS, but when I install games with WINE I get a XDG menu item on my DE.
On macOS you install Wine then Wine runs all .exe files. Is that hard? If .exe files aren't associated with Wine then you can do that yourself from Get Info panel.
In Finder you can use Go to Folder. Just type ~/.wine/drive_c and add Program Files to the sidebar.
I'd like to really Thank Wine developers! Because of your efforts pretty much only time I need to use Windows desktop is when I need Adobe Lightroom CC and Premere Pro and it looks like v4 is improving on that as well.
I remember first trying Wine - I actually installed (well, compiled) XFree86 just to try it - I was proper cli-only in those days. After a long weekend of compiling, I was finally able to run a very slow instance of mIRC - for less than a minute, then it crashed. I was amazed.
2 decades later, my Wife + kids are now able to enjoy The Sims 4 and SimCity on their Linux machines, thanks to the hard work of the Wine team!
And with the additional work of Crossover, Word & Excel too.
These four non-trivial applications, built without any portability in mind, work flawlessly.
That stinks. Considering how well Fortnite is doing, I am a bit surprised that they haven't made a Linux version.
IDK how much it would cost to make a Linux version, but I would think the amount of money from microtransactions they would be getting would make up for it
It must have to do with the lack of profitability, especially after developing an anti-cheat solution.
I'm not 100% certain if EasyAntiCheat supports Wine at all, or even Linux at all, but that's what they (Epic Games) use. If not, they'd have to write an in-house solution that probably won't work.
In the past (again, I'm not sure about the present), CS:GO was victim to having a Linux client; rather, people figured out that it was much more vulnerable to exploits due to it not having a working anti-cheat solution.
> I'm not 100% certain if EasyAntiCheat supports Wine at all, or even Linux at all, but that's what they (Epic Games) use.
It does. EAC detects Wine, and can load a Wine version if the developers enable it. There have also been a few cases where they enabled it upon player requests (without dev involvement).
Switch being mobile is probably why I haven't bought it; we have WiiU, Wii, Gamecube, N64, but my kids if allowed would eschew being sociable in favour of playing Switch everywhere.
We could get it and not let them take it anywhere, but we moved to Steam on Linux pretty much.
Wine Is Not an Emulator - but to run x86 Windows applications on an ARM Android device with Wine you will need to use emulation.
Wine is essentially just a userspace implementation of the Windows API. Outside of API functions & syscalls, the actual instructions of the application are still running on bare metal.
It's available on Android but still pretty broken. You can CD to your SD Card but not list the directory content. You can run executables but dependencies are an issue if you don't know which ones you need to have installed in advance. I bought an x86 Android Notebook/Tablet with the purpose of hoping to be able to run some old Win32 games within Wine on Android and nothing worked.
As one of my buddies said about a laptop I had issues with getting hardware recognized correctly in Linux: Put it in the drawer for 6 months and hope it's fixed by then.
Last time I checked it worked for Android on x86, since wine is not an emulator. I do recall there being some experiments with wine running on arm via. A x86 emulator.
I'm Debian user and I usually install the packages, and the shipped version of the software is just fine for me.
Occasionally I may want to use the newest version of a particular application and I've found that instead of installing dependencies and compiling myself the Linux version, it is way easier to download the Windows binaries and run them with WINE. In some cases, it even works better! (e.g. full screen support)
Back in the day, I dreamt of being able to run Cubase on Wine, and not have to deal with Windows at all, but I remember being told (this was maybe 2002?) by someone who claimed to have the inside line that there was the possibility that Cubase would run on Linux 'soon', natively.
That became less of an issue when Windows 7 came along as it worked so well, but now I know the next hardware revision of my studio PC will probably need to run Windows 10 (which I detest using), I'm looking misty-eyed at it again. But I know that Cubase is immensely demanding, and no doubt uses lots of odd Windows APIs that Wine doesn't cover (or cover fully), so that's just a pipe dream which gets awoken every time I see a new release of Wine come along and I somewhat foolishly check the app database only to find the last versions to test were years ago and were 'garbage'!
I'm sure you have your reasons (no pun intended) but given all you've said here I'm curious as to why your studio PC isn't a Mac? I've done a bit of recording with bands and have never come across anyone running a recording studio on Windows.
FWIW I'm a Linux user too and as a musician I would love Steinberg et al to pull their fingers out so I can have a dabble in that world. We can but dream.
Am I the only one testing software libraries cross-compiled to windows on wine? I do use Appveyor native, but for debugging tricky issues I rather use wine on Linux or macOS, than spinning up a Windows VM and try to debug it there. I just have to maintain seperate win32 and win64 registries and ENV vars.
When I ran 'port install wine,' I got the "error wine cannot be installed for the configured build_arch 'x86_64' because it only supports the arch(s) 'i386'."
I'm no MacPorts guru, but it looks to me like the package doesn't support building the mixed-arch version (which is a practical requirement for 64-bit Wine, although it's technically possible to build a pure 64-bit version) on newer versions of MacOS (I'm not sure what marketing version "18" corresponds to). Maybe this is related to 32-bit support being deprecated in Mojave?
The "game support" they're talking about is not what you're probably thinking of - Wine has been able to run Solitaire and Minesweeper for quite a while already.
Microsoft didn't like the fact that Munich switched to Linux, so they moved their headquarters to Munich to gain political clout, ushered in a more favorable mayor, and then hired Accenture to release a report claiming that Windows would be more cost-effective.
Most likely there were just bribed by one unnamed company, or promised some investments - the time correlates with expanding their office in Munich. So I would not trust Munich's claims at all. Despite recent whitewashing of Microsoft image they were never practicing a fair business.
If you read some more about the issue, it becomes clear that after an election, the conservative party with long-term ties to Microsoft was happy to reverse the decision.
But they said their problem was that they also needed Windows machines to run line-of-business apps and that it wasn't cost effective, something that Wine is supposed to help with (running Windows apps in Linux).
