30 ms·

> Are win32 APIs proprietary? Yes. And crap. Not in my code bases.

by worik 9d ago

josephg 9d ago
If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection.
- ux266478 9d ago
  Find a way to get ring 0 without touching any system APIs and you can just make your own APIs. My programs shall never say "please."
  - estebank 9d ago
    Your programs shall never grace my systems.
    - DeepSeaTortoise 9d ago
      What makes you think he'll let you have a say in this? Btw, you wanna buy some ~~dea~~ usb sticks?
- rfgplk 9d ago
  > If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection. Not even close to being true. You can invoke syscalls directly, just needs a bit of reverse engineering. I wrote a bare metal libc library, with (not a whole lot of) effort I'm fully able to interface with the kernel/open windows etc. Fully statically linked, no libc, no win32, compiled on Linux executed on Windows. The problem is this isn't really well documented _at all_, and I even ended up attempting to get in touch with the Windows kernel dev team to give me the actual internal syscalls/endpoints, but they refuse to cooperate. Which is why writing anything for Windows is entirely pointless.
  - miki123211 9d ago
    The problem is much deeper than that. Most OSes' syscall ABIs are not stable and could change without warning. What is stable is the dynamically-loaded libraries, shipped as part of the system. Linux is the notable exception here; the Linux kernel project doesn't ship a libc, and Linus is very famously opposed to "breaking userspace." There's nothing that can stop you from using syscalls in theory, but if you want your app to be portable across different OS versions, past and future, you'd better not. Incidentally, syscalls would also break Wine. The way Wine works is basically by shipping their own versions of Windows DLLs, which express their operations in terms of Linux APIs. Because Windows programs don't rely on syscalls, and call all system functions via the system-provided libraries, the Wine loader can just link Wine's version and let the program work normally.
    - bentcorner 9d ago
      https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/
    - uncle_kostya 8d ago
      If I recall correctly, the Golang team got bitten by this on MacOS. They initially implemented the Golang runtime directly on top of MacOS syscalls (not the C runtime library), just like they did on Linux - and then those syscalls changed, breaking Golang. They had to switch to the official stable API which on MacOS is the C runtime library, not syscalls.
  - vhiremath4 9d ago
    > This isn’t even close to being true. Here’s a thing I did that made things way more complicated than is worth it for 99% of developers when there is a proprietary solution made so I do not need to worry about these things. Because it is so hard to work around it, it is entirely pointless to develop for one of the most used operating systems in the world. Just being totally honest this is how I read this comment when I insert context that seems important to me. I respect having principles but at some point there needs to be more value in practicality over your codebase not being locked into a proprietary framework at all.
- worik 9d ago
  > If you're going to make apps in windows ...your troubles are starting
fsloth 9d ago
The CPU on most machines is quite proprietary. I don’t understand this faux purity dogma. Practical computing is not and never has been an abstract pure concept. It’s about making machines built by corporations to do usefull things at scale. There is no ”non proprietary” computing unless you make your own stack.
- preg_match 9d ago
  Yes but there are business costs to using high-level proprietary tools and libraries. If you write your app using win32, you won’t be able to port is very easily. You’re also stuck with whatever bad or bizarre decisions Microsoft made. It’s even worse for CUDA. GPUs are expensive, and now you’re vendor locked. You’re between a rock and a hard place. Either spend millions in engineering time, or millions on price-gauged hardware.
  - pjmlp 9d ago
    I wonder which APIs you would use to port easily, because POSIX and Khronos aren't it either, as they are industry standards driven by companies where one has to pay for a seat at Open Group and Khronos offices.
    - fsloth 9d ago
      There is no ”easy” porting. Once this is accepted the rest becomes easier as you are not wasting time trying to find a silver bullet. I mean it’s then ”just normal work”.
      - pjmlp 9d ago
        Exactly.
  - socalgal2 9d ago
    > If you write your app using win32, you won’t be able to port is very easily. Is this still true? eg, Shopify saying porting is now easy so no need for abstractions.

> Are win32 APIs proprietary? Yes. And crap. Not in my code bases.

by worik 9d ago

> Are win32 APIs proprietary? Yes. And crap. Not in my code bases.

If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection.

ux266478 9d ago
Find a way to get ring 0 without touching any system APIs and you can just make your own APIs. My programs shall never say "please."
- estebank 9d ago
  Your programs shall never grace my systems.
  - DeepSeaTortoise 9d ago
    What makes you think he'll let you have a say in this? Btw, you wanna buy some ~~dea~~ usb sticks?
rfgplk 9d ago
> If you're going to make apps in windows, you need to call their proprietary API somehow. Maybe you do it via a wrapper library, or via electron or something. But that's the same thing, just with more indirection. Not even close to being true. You can invoke syscalls directly, just needs a bit of reverse engineering. I wrote a bare metal libc library, with (not a whole lot of) effort I'm fully able to interface with the kernel/open windows etc. Fully statically linked, no libc, no win32, compiled on Linux executed on Windows. The problem is this isn't really well documented _at all_, and I even ended up attempting to get in touch with the Windows kernel dev team to give me the actual internal syscalls/endpoints, but they refuse to cooperate. Which is why writing anything for Windows is entirely pointless.
- miki123211 9d ago
  The problem is much deeper than that. Most OSes' syscall ABIs are not stable and could change without warning. What is stable is the dynamically-loaded libraries, shipped as part of the system. Linux is the notable exception here; the Linux kernel project doesn't ship a libc, and Linus is very famously opposed to "breaking userspace." There's nothing that can stop you from using syscalls in theory, but if you want your app to be portable across different OS versions, past and future, you'd better not. Incidentally, syscalls would also break Wine. The way Wine works is basically by shipping their own versions of Windows DLLs, which express their operations in terms of Linux APIs. Because Windows programs don't rely on syscalls, and call all system functions via the system-provided libraries, the Wine loader can just link Wine's version and let the program work normally.
  - bentcorner 9d ago
    https://blog.hiler.eu/win32-the-only-stable-abi/ https://blog.hiler.eu/win32-the-only-stable-abi/
  - uncle_kostya 8d ago
    If I recall correctly, the Golang team got bitten by this on MacOS. They initially implemented the Golang runtime directly on top of MacOS syscalls (not the C runtime library), just like they did on Linux - and then those syscalls changed, breaking Golang. They had to switch to the official stable API which on MacOS is the C runtime library, not syscalls.
- vhiremath4 9d ago
  > This isn’t even close to being true. Here’s a thing I did that made things way more complicated than is worth it for 99% of developers when there is a proprietary solution made so I do not need to worry about these things. Because it is so hard to work around it, it is entirely pointless to develop for one of the most used operating systems in the world. Just being totally honest this is how I read this comment when I insert context that seems important to me. I respect having principles but at some point there needs to be more value in practicality over your codebase not being locked into a proprietary framework at all.
worik 9d ago
> If you're going to make apps in windows ...your troubles are starting

fsloth 9d ago

The CPU on most machines is quite proprietary. I don’t understand this faux purity dogma. Practical computing is not and never has been an abstract pure concept. It’s about making machines built by corporations to do usefull things at scale. There is no ”non proprietary” computing unless you make your own stack.

preg_match 9d ago
Yes but there are business costs to using high-level proprietary tools and libraries. If you write your app using win32, you won’t be able to port is very easily. You’re also stuck with whatever bad or bizarre decisions Microsoft made. It’s even worse for CUDA. GPUs are expensive, and now you’re vendor locked. You’re between a rock and a hard place. Either spend millions in engineering time, or millions on price-gauged hardware.
- pjmlp 9d ago
  I wonder which APIs you would use to port easily, because POSIX and Khronos aren't it either, as they are industry standards driven by companies where one has to pay for a seat at Open Group and Khronos offices.
  - fsloth 9d ago
    There is no ”easy” porting. Once this is accepted the rest becomes easier as you are not wasting time trying to find a silver bullet. I mean it’s then ”just normal work”.
    - pjmlp 9d ago
      Exactly.
- socalgal2 9d ago
  > If you write your app using win32, you won’t be able to port is very easily. Is this still true? eg, Shopify saying porting is now easy so no need for abstractions.