6 ms·

My first job out of university was in a company that developed a GUI appication based on the Win32 C API. In fact, the product has been on the market for so lon

My first job out of university was in a company that developed a GUI appication based on the Win32 C API. In fact, the product has been on the market for so long, that it's code had been a Win16 application in the past and pre-dated Win 3.1 (It is a product for a niche market, and had been the first Windows program on the market there, with all other software being MS-DOS Applications). So, I came from university, had written Software during my master thesis with Qt, had some exposure to Gtk on my home PC a few years before, and I faced this obscure Win32 API, which looks ugly, appaling, antiquated and plainly awful. But: Development was actually quite pleasant, and, while it didn't offer the flexibility of full-blown object oriented libraries like Gtk or Qt, it was amazingly good at getting stuff done. I wouldn't start a new project in it of course and it seems Microsoft has pretty much abandoned the API. But, I have to admit that I can see how it served Microsoft and its developer community well for a few years. In fact, a lot of things in there where quite thoughtful and I can still appreciate the non-bloaty way of doing things, if I see how many processes and memory an electron app uses that doesn't do much more than what a simple Win32 program does.

jussij 7y ago
> and I faced this obscure Win32 API, which looks ugly, appalling, antiquated and plainly awful. As you point out, the code you had to deal with was actually written using the Win16 API. That Win16 API dates back to the first ever version of Windows which takes you back to a pre 1990 era. As someone who did work on both Win16 and Win32, what I found amazing is Microsoft designed Win32 such that you could take your Win16 code, do a minimal number of changes and recompile that code for Win32. That meant you could take your old Win16 code designed for a now obsolete version of Windows, do a minimal number of tweaks, recompile the code using a 32 bit compiler and have it running on the most resent 32 bit versions of Windows. It was my first experience of a major coding upgrade and it was the last such upgrade that was anywhere near as simple as that upgrade.
- unalignedaccess 7y ago
  > and have it running on the most resent 32 bit versions of Windows. Or 64-bit, for that matter.
  - moron4hire 7y ago
    Well, those 32-bit apps run in a hypervisor. The compatibility is so good because you have both 64-bit and 32-bit Windows in your 64-bit installation.
    - deleted 7y ago
      [deleted]
    - skissane 7y ago
      32-bit apps running on 64-bit Windows run using a Windows component called "WoW64". There is another compatibility layer used to run 16-bit apps on 32-bit Windows called "WoW". Neither "WoW64" nor "WoW" are usually referred to as "hypervisors". That term is usually reserved for systems which run a full operating system using CPU virtualisation technology – Hyper-V, VMWare, VirtualBox, Xen, KVM, etc. By contrast, WoW64 and WoW are rather thin translation layers. WoW64 just intercepts the 32-bit API calls, translates the parameters, invokes the 64-bit API, and then translates the results back to 32-bit. (WoW does basically the same thing for 16-bit calls to 32-bit.) This is possible because all of the Win32 API calls have Win64 equivalents (likewise, most Win16 API calls have Win32 API equivalents, except for a handful of obscure Win16 APIs which newer versions of Windows don't support.) WoW runs under NTVDM which uses virtual 8086 mode, so you might call WoW a "hypervisor" in that sense (although the hypervisor is really NTVDM not WoW.) But WoW64 does not use any virtualisation technology at all.
- wirrbel 7y ago
  Over the decades a lot of win32 code was written. You can expect that all changes from 1995 on were win32 API only
unalignedaccess 7y ago
WTL is a great attempt at creating a close-to-zero-cost C++ library around the Win32 UI architecture. I use it sometimes even today, and it's not bad considering the age of the foundations.
- Ididntdothis 7y ago
  Yeah. It was a very good start but as usual MS abandoned it before it could get really good.
  - tonyedgecombe 7y ago
    They never really embraced it despite it being used internally for several projects.
  - Crinus 7y ago
    AFAIK WTL is still being developed as an open source project by the same main developer who originally made it.
  - dragontamer 7y ago
    WTL continues on as an open-source project, supporting the latest updates to Win32 API in Windows 8 and Windows 10.
- _pmf_ 7y ago
  Do you use it in open source projects of commercial applications? If the former, I'd be interested in looking at it. I think xplorer² is written using WTL.
bni 7y ago
"Microsoft has pretty much abandoned the API" No they havent. Everything else in Windows land is just built on top of it. I also made some Win32 development at one point. The programs made using only Win32 have a very snappy and light weight feel to them that is very nice. It is fairly low level and more for the machine than for humans. But I doubt you can have both of these things.
- userbinator 7y ago
  No they havent. Everything else in Windows land is just built on top of it. There were even some articles recently about that: https://news.ycombinator.com/item?id=19883351 https://news.ycombinator.com/item?id=19883351 https://news.ycombinator.com/item?id=19873198 https://news.ycombinator.com/item?id=19873198 I started with a bit of Win16 and then moved to Win32, and don't really see why it gets a lot of hate; it's not perfect, but it looks like it does exactly what it was meant to do, and does it well. Perhaps it's because all of the tiny and fast applications I've used in the past were pure Win32. You can do a lot with it in only a few KB or tens of KB. In contrast, I don't find all the other multi-megabyte UI frameworks appealing.
  - ChrisSD 7y ago
    Those articles seem overblown. Providing access to UWP APIs from regular desktop apps will, if anything, increase the number of applications using those APIs. UWP GUI APIs could be especially attractive option to those applications currently using win32 forms.
    - Crinus 7y ago
      I wonder how exactly will those WinUI (or UWP GUI) APIs will be used in practice though. The vast majority of applications that still use Win32 do it through some sort of framework (be it wxWidgets, MFC, VCL/LCL, etc) that has specific assumptions about what desktop applications are and how they are made. From what i've seen, mixing WinUI and Win32 on the same application kinda feels like dropping a web control in a VB6 application and using HTML+JS to create the UI (which ignores pretty much all the strengths of VB6 while retaining all the limitations). I have a hard time imagining why anyone who isn't forced to use WinUI in their Win32 application (forced in the sense that some middle manager heard about it and believes it is a good idea so forces the developers to use it) would use it in the first place. I mean, many applications/frameworks do not even use stuff available through COM since Vista and instead prefer to recreate them using the plain C APIs and that is for a seemingly simpler and more understood variety of COM.
gdxhyrd 7y ago
Abandoned? Every single Windows application uses it, regardless of the language, framework or anything else. It is the equivalent to Linux syscalls, since it is the lowest stable layer in Windows land.

jussij 7y ago

> and I faced this obscure Win32 API, which looks ugly, appalling, antiquated and plainly awful. As you point out, the code you had to deal with was actually written using the Win16 API. That Win16 API dates back to the first ever version of Windows which takes you back to a pre 1990 era. As someone who did work on both Win16 and Win32, what I found amazing is Microsoft designed Win32 such that you could take your Win16 code, do a minimal number of changes and recompile that code for Win32. That meant you could take your old Win16 code designed for a now obsolete version of Windows, do a minimal number of tweaks, recompile the code using a 32 bit compiler and have it running on the most resent 32 bit versions of Windows. It was my first experience of a major coding upgrade and it was the last such upgrade that was anywhere near as simple as that upgrade.

unalignedaccess 7y ago
> and have it running on the most resent 32 bit versions of Windows. Or 64-bit, for that matter.
- moron4hire 7y ago
  Well, those 32-bit apps run in a hypervisor. The compatibility is so good because you have both 64-bit and 32-bit Windows in your 64-bit installation.
  - deleted 7y ago
    [deleted]
  - skissane 7y ago
    32-bit apps running on 64-bit Windows run using a Windows component called "WoW64". There is another compatibility layer used to run 16-bit apps on 32-bit Windows called "WoW". Neither "WoW64" nor "WoW" are usually referred to as "hypervisors". That term is usually reserved for systems which run a full operating system using CPU virtualisation technology – Hyper-V, VMWare, VirtualBox, Xen, KVM, etc. By contrast, WoW64 and WoW are rather thin translation layers. WoW64 just intercepts the 32-bit API calls, translates the parameters, invokes the 64-bit API, and then translates the results back to 32-bit. (WoW does basically the same thing for 16-bit calls to 32-bit.) This is possible because all of the Win32 API calls have Win64 equivalents (likewise, most Win16 API calls have Win32 API equivalents, except for a handful of obscure Win16 APIs which newer versions of Windows don't support.) WoW runs under NTVDM which uses virtual 8086 mode, so you might call WoW a "hypervisor" in that sense (although the hypervisor is really NTVDM not WoW.) But WoW64 does not use any virtualisation technology at all.
wirrbel 7y ago
Over the decades a lot of win32 code was written. You can expect that all changes from 1995 on were win32 API only

unalignedaccess 7y ago

WTL is a great attempt at creating a close-to-zero-cost C++ library around the Win32 UI architecture. I use it sometimes even today, and it's not bad considering the age of the foundations.

Ididntdothis 7y ago
Yeah. It was a very good start but as usual MS abandoned it before it could get really good.
- tonyedgecombe 7y ago
  They never really embraced it despite it being used internally for several projects.
- Crinus 7y ago
  AFAIK WTL is still being developed as an open source project by the same main developer who originally made it.
- dragontamer 7y ago
  WTL continues on as an open-source project, supporting the latest updates to Win32 API in Windows 8 and Windows 10.
_pmf_ 7y ago
Do you use it in open source projects of commercial applications? If the former, I'd be interested in looking at it. I think xplorer² is written using WTL.

bni 7y ago

"Microsoft has pretty much abandoned the API" No they havent. Everything else in Windows land is just built on top of it. I also made some Win32 development at one point. The programs made using only Win32 have a very snappy and light weight feel to them that is very nice. It is fairly low level and more for the machine than for humans. But I doubt you can have both of these things.

userbinator 7y ago
No they havent. Everything else in Windows land is just built on top of it. There were even some articles recently about that: https://news.ycombinator.com/item?id=19883351 https://news.ycombinator.com/item?id=19883351 https://news.ycombinator.com/item?id=19873198 https://news.ycombinator.com/item?id=19873198 I started with a bit of Win16 and then moved to Win32, and don't really see why it gets a lot of hate; it's not perfect, but it looks like it does exactly what it was meant to do, and does it well. Perhaps it's because all of the tiny and fast applications I've used in the past were pure Win32. You can do a lot with it in only a few KB or tens of KB. In contrast, I don't find all the other multi-megabyte UI frameworks appealing.
- ChrisSD 7y ago
  Those articles seem overblown. Providing access to UWP APIs from regular desktop apps will, if anything, increase the number of applications using those APIs. UWP GUI APIs could be especially attractive option to those applications currently using win32 forms.
  - Crinus 7y ago
    I wonder how exactly will those WinUI (or UWP GUI) APIs will be used in practice though. The vast majority of applications that still use Win32 do it through some sort of framework (be it wxWidgets, MFC, VCL/LCL, etc) that has specific assumptions about what desktop applications are and how they are made. From what i've seen, mixing WinUI and Win32 on the same application kinda feels like dropping a web control in a VB6 application and using HTML+JS to create the UI (which ignores pretty much all the strengths of VB6 while retaining all the limitations). I have a hard time imagining why anyone who isn't forced to use WinUI in their Win32 application (forced in the sense that some middle manager heard about it and believes it is a good idea so forces the developers to use it) would use it in the first place. I mean, many applications/frameworks do not even use stuff available through COM since Vista and instead prefer to recreate them using the plain C APIs and that is for a seemingly simpler and more understood variety of COM.

gdxhyrd 7y ago

Abandoned? Every single Windows application uses it, regardless of the language, framework or anything else. It is the equivalent to Linux syscalls, since it is the lowest stable layer in Windows land.