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

The thing is UNIX, by definition, is never going to move beyond its original design, meaning POSIX + C.

Whereas Mac OS, Windows, iOS, Android, ChromeOS have moved into more productive language runtimes, with rich frameworks, improving safety across OS layers, even if they have a few bumps along the way.

That's not true. Windows in particular is greatly limited by past design choices, such as filename limitations, the security model, the fact that many programs have to be run as administrator because that's how they were written years ago, etc.

There's nothing preventing you from running different language runtimes and such on Linux/Unix systems; people do it all the time. Have you not noticed Mono? It's been around for many years. Plus frameworks like Qt; that certainly wasn't around before the late 90s.

Windows 10 already sorted out the filename limitations.

A few more releases and in around 10 years, Win32 will be drinking beers with Carbon.

Mono and Qt don't change the architecture of UNIX and their adoption across UNIX variants isn't a game changer.

>Windows 10 already sorted out the filename limitations.

No, it hasn't. Filenames are still case-insensitive (and in a terrible way, where it seems to remember how they were first typed but that can never be changed), backslashes are still used for path separators instead of escaping characters, and the worst of all is that drive letters are still in use, which is an utterly archaic concept from the days of systems with dual floppy drives. Also, try making a file with a double-quote character in it, or a question mark. I've run into trouble before copying files from a Linux system to a Windows system because of the reserved characters on Windows.

>Mono and Qt don't change the architecture of UNIX and their adoption across UNIX variants isn't a game changer.

Nothing you've mentioned has changed the architecture of Windows. The fundamental architecture of Windows hasn't changed at all since WinNT 4.0 (or maybe 3.5); it just has an ugly new UI slapped on top and some slightly different administration tools.

Windows NT (the core OS) suffers none of those problems.

The Windows (Win32) environment suffers those limitations. It also suffers 20+ years of strong binary compatibility, broad hardware support, and consistent reliability that systems of similar class (e.g. Linux desktops) can't match.

If it makes you feel any better, drive letters are a convenient illusion made possible by the Win32 subsystem; NT has no such concept and mounts file systems into the object hierarchy (NT is fundamentally object oriented - a more modern and flexible design than is provided by UNIX).

The fundamental architecture of Windows, the kernel, hasn't changed in ages because it doesn't need to; it is far more sophisticated than UNIX will ever be and far more sophisticated than you will ever need. The fundamental architecture of Win32 hasn't changed since 32-bits was an exciting concept and it won't change because the market has said loud and clear that they want Windows-level compatibility. See Windows RT and The Year of the Linux Desktop for evidence that users aren't clamoring to ditch Win32 in favor of something more pure.

> The fundamental architecture of Windows, the kernel, hasn't changed in ages because it doesn't need to; it is far more sophisticated than UNIX will ever be and far more sophisticated than you will ever need.

Another case in point: it allowed MS to write a layer on top of the NT kernel to run unmodified Linux binaries. (Windows subsystem for Linux).

Linux has the same thing, called WINE. It already works quite well, and if they had access to the Windows and Win32 source code and a staff of full-time developers, it'd work flawlessly.

An API translation layer doesn't prove that a kernel is "more sophisticated" than another; that's just fanboyism.

> consistent reliability

Is that a claim you can substantiate? I admit I stopped paying attention around the time that scale-up of expensive servers with high minimum specs + expensive software licenses was overtaken by scale-out approaches + open source, but NT never struck me as being particularly stable in the face of badly written software and drivers. Has it improved a lot in this dimension over the past 15 years?

Is there a possibility to use the NT system without the flaws (?) of Win32? I hardly know anything about Windows programming, and I'm a bit curious now, having read your comment.

Windows exposes personalities above the kernel, in the NT days that meant OS/2 1.x, POSIX and Win32.

Nowadays on Windows 10 it means UWP, Win32 and Linux syscalls.

In theory someone could call the ntdll.dll and create a new personality but those APIs are undocumented and only possibly made available to Microsoft partners.

Complaints of a UNIX refugee on Windows.

For us, Windows pathanmes are just fine.

As for Windows architecture, maybe you should spend some hours reading Windows Internals book series, BUILD and Channel 9 sessions about MinWin, Drawbridge, Picoprocesses, UWP, User Space Drivers, Secure Kernel,....

>you should spend some hours reading Windows Internals book series

I'd love to read the source code myself to see how it works instead

Google "davec apcobj.c"; that'll point you in the direction of some of Dave's brilliant work that dates back to 1989.

(Three versions of NT have been leaked; NT 4.0, Windows 2000, an the Windows Research Kit (which is Win2k3) -- they are all trivial to find online (first page of Google results).)


Not exactly "you can get it if you want it", but not "you can't even get it over our dead body", either.

You can check out ReactOS which works like Windows but is open source.

> Windows 10 already sorted out the filename limitations.

Only for new applications. These written for the old ABIs still trip over after the 240th character, even though the FileSystem supports much more.

To put in another words: I belive the inherent unix limitations (process model for terminals, process signalling, lack of structure) are still less limiting than DOS assumptions about the consumer hardware and applications of the 80's.

You are moving the goal posts from OS limitations to limitations of old applications.

Unix applications written using old assumptions (e.g. ?14? characters max for symbol names in libraries, ?16? bit address space, assuming the C library knows of gets) can have problems on modern systems, too.

No one still uses Unix applications from the 1970s.

Lots of people still use Windows applications with the limitations mentioned here, either because they refuse to give up their 1990s Windows applications, or the weird little ISVs refuse to update their code.

Old, badly written, programs requiring admin was a problem the first year after Vista was released. Today, not anymore.

All programs of interest have migrated and there is also a compatibility layer redirecting older programs to write to a fake system directory.

What do you mean by unix in this context? Everything save for windows bears a strong kinship with Unix and every OS is more than capable of running additional runtimes and frameworks beyond C.

UNIX and C are symbiotic, regardless of whatever runs on top, only POSIX and C are common to any UNIX.

Windows roots are on VMS, not UNIX. There is hardly anything UNIX related on its architecture, regarding kernel design.

It was an OpenVMS derivative wiyh code copied or clean-slated against a modified form of its behavior. However, I heard the networking stack was from BSD.

Thanks for the tip.

The IP stack is. There's even still an etc/ directory buried in the Windows tree to support it.

This is no longer true, the TCP/IP stack was rewritten on Windows Vista.


>only POSIX and C are common to any UNIX.

What about something like this: https://www.redox-os.org/

Its written in Rust not C. In fact, according to the github stats, there is no C.

>Rust 72.4%

>Shell 13.2%

>Makefile 12.5%

>TeX 1.9%

Yes, but Redox is not UNIX.

Registration is open for Startup School 2019. Classes start July 22nd.

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