dingu

It's visually a nice collection. As a documentary it is pretty inaccurate in a number of key areas. The BBS Documentary has a very nice and accurate treatment (interviews with actual people from the scene) if one is interested.

Ah you edited your response? An HMODULE.. That is weak dude. Calling and HMODULE a HANDLE is cheating... by that definition a UINT is a HANDLE since you can cast it.

Can you use HMODULEs orthogonally to common APIs that use Handles? That's what really matters. Just because something is 4 or 8 bytes wide and you call it the same thing isn't interesting. Like can you pass HMODULE to WaitForSingleObject? Oh Ok, I guess that's mean because to be fair, what does "waiting" on a DLL mean.

Ok, well surely you can pass that HMODULE to CloseHandle, at least closing should be orthogonal.. Why don't you try that? I'll wait.

So what point are you trying to make here? It sound like you're just jerking everyone around, tbh.

Edit: Moreover, it's a bit ridiculous to say that an HMODULE is just an address with no kernel state. It uniquely identifies the loaded DLL, so it a key to a tremendous amount of kernel bookkeeping about the loaded module.

What does that have to do with anything? You wouldn't use WFMO to implement a futex in Windows. And regardless of anything in Linux, defending WFMO seems like a strange hill to die on. It's not a great API.

I'm calling your bluff too. Which one of the supported waitable handles in Windows are just addresses with no other state? I'm more surprised because they all need an access mask at a minimum, and I thought they all involve an ObCreateObject, even a Mutant... these dusty corners of the kernel are visible through the DDK. Anyway, I would be glad to be shown wrong.

what are you on about? I just gave you the specific examples: timerfd, eventfd, signalfd, inotify... these are all epollable fds in Linux?

Futex is a special case because futexes themselves are quite special. There is no userspace equivalent to them in Windows anyway as has been mentioned. Windows Events are similar to what is provided by eventfd, but not as featureful.

You are confused. File descriptors on linux represent "many different types." They are not just for "disk files". Please see signalfd, timerfd, eventfd, inotify, let alone sockets (which themselves represent things other than IP sockets). FD is essentially like handle. epoll therefore works with many different types.

epoll was a problem child API on linux, with a number of missteps early on. It's much better now. It does everything WFMO does and more. What disjoint APIs are you talking about? You can just use epoll and be done with it?

What are you talking about by "wait for both"?

But jesus, the windows API in this area is hot garbage. A hard 64 limit and O(N)? It's a terrible design.

Having written a fair share of deeply embedded assembly.. if you're used to writing this close to the metal on a small system, that may have actually have been the most straight-foward way. Since ultimately the score must be rendered to the screen, and that might be its only purpose, there was probably little point in holding a "raw" intermediate value. Adding a constant and a few instructions for rollover don't sound too bad in the grand scheme of things.

People use systemd because it solves real problems that are not adequately solved by init scripts. Your "want for nothing" says more about your limited needs (which is fine) than anything else about system management services.

Regardless of one's opinions or critiques about the implementation of systemd specifically, the idea that it came up in some kind of vacuum or started a "trend" is utterly ridiculous.

Prior art in UNIX would be SMF at a minimum, and systemd clearly looked at launchd for some inspiration in other areas (systemd ended up having the goal of covering both use cases of launchd and SMF.. ie generally server and desktop).

Also what is this about binary blobs? systemd is configured with text files. Last I checked, the init process itself on BSD is a binary.