Hacker News Reader

Comment by blobjectivism | Hacker News Reader

>A library written in C can be used by anyone else.

This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't true on Windows until linux compatibility was developed on it.

>If you're one of the very many people who look down their noses at C and want to get rid of it, do your part.

convincing linus and sysadmin greybeards to modernize linux and is no small task, until then we'll all still be just be scripting over archaic C apis

"science progresses one funeral at a time"

View on HN

> This is because of how much of the unix clone ecosystem has been built around C workflows

Absolutely correct.

> convincing linus and sysadmin greybeards to modernize linux

That's not what I'm suggesting. Anything that's already written in C can and probably should continue to be so. What I'm suggesting is that people who prefer to work in other languages should have an easy way to make their work available beyond their own language community. I'm not talking about interpreted/scripting languages here. I'm talking about compiled/systems languages. Stuff that gets linked together, or that should be able to use some sort of dlopen/FFI back and forth fluidly despite multiple languages being involved. There's some work to be done there, but everyone seems to prefer hiding in their own language bunker instead of reaching out to others.

There are solutions, but only at platform level.

JVM, CLR, COM, UWP, DEX, TIMI, ILE are all possible approaches with various degrees of success and most of them also have C implementations available.

It is almost impossible to get some kind universal ABI between OSes and languages without an extra level of indirection.

The problem is that other languages necessarily place more restrictions on how their data can be used in order to gain all their nice features. Since you can't control the caller you lose all those guarantees. Because of that it will never be easy to interop across higher level languages. C works well here because its low level enough that it expects few guarantees. Just keep the stack aligned and balanced and it will mostly be happy.

>>> This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't true on Windows until linux compatibility was developed on it.

Windows is almost entirely coded in C. The Windows C API is one of the most depended upon API with the largest codebase and the longest documentation in existence.

Kind of.

After Longhorn's failure, they started to focus on COM to be the future of Windows APIs, leading to UWP.

And if masochists can implement COM in C, they need to be quite pain resistant for the UWP update.

In the meantime, the new C runtime was rewritten in C++, using extern "C" entry points.

Windows drivers can be written in C++ since Windows 8, and since then they have been migrating the code to be compilable as the C subset from C++ as well.

I meant the base Windows API. The MFC and COM were built to abstract it but never really took off.

The low level API have been fixed for a very very long time. It doesn't really need to change, opening a file is not different now than a decade ago. It gets no love and no popularity, but it runs the world.

Most development is done in higher languages nowadays, typically C#, java or python and all these languages rely on the Windows API to run. They are abstractions of C.

P.S. Drivers could already be written in C++ since Windows XP. There were a lot of constraints though because of running in the kernel.

> The MFC and COM were built to abstract it but never really took off.

MFC was the way to write real Windows applications until .NET came around.

Visual Basic was mostly used by not so skilled developers, creating applications that IT department had to take care of, sometimes rewriting them into MFC ones.

Delphi and C++ Builder were the only solid alternatives outside Microsoft world, but thanks to the way they drove prices upwards and the identity crisis from Borland, most developers went away to Microsoft products, as the platform is always a safer better for development tools.

As I mentioned, since Windows Vista all new API are COM, and UWP, which is the future of the platform is COM as well.

UWP is what .NET was supposed to be initially, COM+ Runtime, just that UWP uses .NET metadata instead of COM type libraries and allows for real instances, not only interfaces.

COM is a first class type in .NET given its original design, many of the .NET APIs are COM objects underneath, including the whole CLR native APIs.

Drivers written in C++ on XP only by adventurous coders with their own compilers or hacks somehow, as Visual C++ only supports kernel mode since Windows 8.

> It doesn't really need to change, opening a file is not different now than a decade ago

Actually it has changed.

OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2().

And on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store.

And if you want to use any of the goodies from Windows 8 onwards, they are only available as UWP APIs.

> on Windows 10, CreateFileFromApp() and CreateFile2FromApp() should be used instead, otherwise the application won't run from the store.

So?

If you dislike the app store monopolies, it's stupid to herd your users into the store. Tell your users that your app is too sophisticated to run in dummy mode. Bonus: Sell to all the Win7 holdouts.

If you love app stores (monopoly rents be damned), you rank the store ecosystems and then never write a Windows version.

You missed the part that given how things turned out, thanks to Project Centennial, there is an ongoing process to bring store containers to whole user space, MSIX.

So regardless of Win32 or UWP, everything will eventually be sandboxed.

Windows 7 is the new XP.

CreateFile() is not deprecated. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

OpenFile() could be considered deprecated but the official documentation doesn't mark it as deprecated.

You missed the point that these API have been stable for decades and software will continue to work without any change.

> CreateFile() is not deprecated. https://msdn.microsoft.com/en-us/library/windows/desktop/aa3....

"OpenFile() has been deprecated and replaced by CreateFile(), which was superseded by CreateFile2()."

I never said CreateFile() was deprecated. Superseded is not the same thing.

> OpenFile() could be considered deprecated but the official documentation doesn't mark it as deprecated.

"Note This function has limited capabilities and is not recommended. For new application development, use the CreateFile function."

Looks pretty much an euphemism for deprecated.

> You missed the point that these API have been stable for decades and software will continue to work without any change.

Not when Windows puts a container around what they can see.

> Windows 7 is the new XP

Win7 is a focal point of some importance: It's where developers who don't want to be pushed into app store indentured servitude join up with the Windows compatible systems, Wine and ReactOS.

Everything before Win7 is not a focal point because it's too old. Everything after Win7 is not a focal point because nobody can handle the update threadmill. By elimination, it's Win7.

Win7 is not the new XP; it's the future of stability-oriented Windows compatible computing.

You don't need anybody's permission to do this. Linux has a language-agnostic system call interface. Everything that happens on the computer is accomplished through that interface, and to use it all you need to do is put some values in specific registers and issue a special instruction. This isn't the domain of C; the JIT compiler could have a special system call generation feature. You could get rid of GNU and write your own user space in Lisp if you wanted to.

Or in Go: https://github.com/google/gvisor

> This is because of how much of the unix clone ecosystem has been built around C workflows, and this wasn't true on Windows until linux compatibility was developed on it.

Because C (and its close relatives like C++) is still the only language suitable for systems development.

Just booting any other language on bare metal is enough of an achievement that people loudly brag when they get it to just barely work. If you get it to work in C then nobody is surprised, because C is engineered for systems. Other languages aren't.

> convincing linus and sysadmin greybeards to modernize linux and is no small task, until then we'll all still be just be scripting over archaic C apis

I'm not sure replacing C with a worse language constitutes "modernizing".

Reply on news.ycombinator.com