Hacker News new | past | comments | ask | show | jobs | submit login

Funny how Wine has implemented Windows APIs on top of Linux (and Mac), and Microsoft has implemented Linux APIs on top of Windows.



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!


> some UI-level APIs

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.


> This assumes that there is agreement on what the UI experience should be. Navigation patterns, menu bars, keyboard shortcuts, touch gestures..

We had that for a while.

https://en.wikipedia.org/wiki/IBM_Common_User_Access

And most DEs even implemented it to some extent. But they didn't converge as a result of that.


> The web is a lowest common denominator.

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).


> I can't recommend CMake enough here

I've used CMake for many years. But now that I've discovered Meson, I cry a little every time I have to edit a CMakeLists.txt file.


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.


IME the documentation is great at a command level but does a poor job of explaining how things fit together at a macro level.

I did a large project conversion last year and was well into it before I started getting a feel for how everything fit together with Public/Private.


But meson used pkg-config under the hood, which looks very unusual/like alien creation for Windows Devs.


These days with stuff like MSYS2 readily available, it's not really as alien as one might think.


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.


One selling point seems to be speed: https://mesonbuild.com/Performance-comparison.html


> don't use platform specific headers

Which is often unavoidable if you want to do filesystem stuff.


Qt and Gtk (or just glib) can handle file systems identically across platforms.


I prefer using boost, if UI is not required


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.


> We're just about due for another doomed effort!

It seems Google will take a shot at it: https://en.wikipedia.org/wiki/Google_Fuchsia


That screenshot looks like Android 2.0. I'll pass, having 1 Android is already too much.


The important part of Fuchsia is not the UI at this point, it's the kernel.


Sounds like you might be interested in POSIX.


One OS. One UI. One experience. One problem if it has a bug or sn architectural deficiency. Zero choice.


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.


"Or sad."

No mate it isn't sad. There is always going to be a scrap between things, whether they be OSs or iguanas and snakes on the Galapagos islands.

I'm going in with a penguin myself and I will win.


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


Or you can just build wine on Windows for Windows. I've done that long time ago for Yuri's Revenge.


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.

https://token2shell.com/x410/


I guess that would be helpful if you wanted to run 16 bit software on 64 bit Windows.


There's NXVDM which is a port of the i860/Alpha/MIPS/PPC NTVDM compiled for AMD64. https://sourceforge.net/projects/nxvdm/


Few use cases I can think of:

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.


Well, you can run Wine on Windows (which makes sense if you think about it).


IIRC you can run wine on cygwin, so I wouldn't be terribly surprised if wine on WSL worked.


Also Docker for Windows can run Windows and Linux containers.


Would be a strong contender for "turtles all the way down" of the year.


I'd suggest running an Amiga emulator. There was a Mac "emulator" for Amiga that required Mac ROMs to function.

Sadly, the Apple II emulator for Macs was real hardware.


If Microsoft wanted to be clever, they would have called their thing Line.


Microsoft bought the term "Lindows" in 2004 for around $20 million.

https://en.wikipedia.org/wiki/Microsoft_Corp._v._Lindows.com....


In retrospect, prescient and especially useful when they will release their own Linux distribution.

I'd bet on them forking or outright buying Ubuntu.


> outright buying Ubuntu.

Calm down there Satan.


I've always preferred mslinux http://www.mslinux.org/


> Microsoft Invades Cuba

> 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.


Sounds like Amazon


who owns Ubuntu?


Canonical


The name has already been taken: https://sourceforge.net/projects/line/


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.


Even funnier is that often Wine has better performance than native Windows.


Will Wine run on top of Windows Subsystem for Linux?


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.


same with programming languages, js/python/perl cross pollinated each others a lot




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: