![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Here's to 2019.
Been a couple minutes. My understanding of the Windows API is starting to come together, and it's simultaneously hyper-enriching and terrifying-- I didn't know it was that bad, but I didn't know it was that simple, either. The sensation is skin to getting just enough study in where, looking at a foreign language, you're understanding 50% of the words where in the past you got 5-10% at best.
To something-like-summarize...
The windows API -- as in, the code you write, functions you call, kernel bits you prod, etc. to spawn windows and get them talking -- has not changed in many backwards-incompatible ways in something like thirty years. Windows 10 seems to have tried (and to some extent failed) to deprecate Win16, ie. the API calls specific to Windows 3.1 and prior, but it's not comparable to Apple's deprecation of PowerPC.
New overlays (eg. MFC), new 'translations' (eg. every library portable to Windows), new frameworks (eg. .NET), but nothing excised.
Considering part of the reason I cling to C so tightly is because of Linux-and-co's long-lived tradition with it, this makes me much more comfortable writing code for Windows. If still a little horrified.
Mostly because Windows' development tradition is in C++, not C. The peppering of 'object' and 'component' everywhere is a hint. And C is largely an afterthought these days. (Often a contemptuous afterthought lending to my overall silence.) WinRT, the 'new' API going forward, doesn't officially support C at all, though you can still make it work.
Ah well. With the general allergy to the console I imagine it's a bit like coding for the Mac was back in the 90s. At any rate, nothing really changes for anyone else other than seeing a spare 'cygwin.dll' lying around; one of my priorities is giving people a single EXE or the like to click/drag/interact with, because that makes the most sense on Windows, and while Node's 'uhh run the engine and...' approach on Windows violates this, dynamic linking does not. (OSX is much better-suited for Node's... situation, when it comes to packaging and distributing Electron apps and such. Yes, I know you can 'compile' Node more tightly. It also takes an extra toolchain whereas compiling C is a built in functionality. Also, it's Node.)
I'm making a few smaller applications before I get back to the main meat. Notably, a little tool with sockets so that I can be pinged without being aggravated (TCP/IP code, JSON in C, tray applications...), and an egg timer that doesn't suck (timers, shaped windows, multithreading...). I have been pressed into using hourglass for the latter since my OS hop and ... by some quirk of my system it takes nearly 30 seconds to open every time. I don't dare speculate which quirk that is, knowing what I know now about Win32.
Been a couple minutes. My understanding of the Windows API is starting to come together, and it's simultaneously hyper-enriching and terrifying-- I didn't know it was that bad, but I didn't know it was that simple, either. The sensation is skin to getting just enough study in where, looking at a foreign language, you're understanding 50% of the words where in the past you got 5-10% at best.
To something-like-summarize...
The windows API -- as in, the code you write, functions you call, kernel bits you prod, etc. to spawn windows and get them talking -- has not changed in many backwards-incompatible ways in something like thirty years. Windows 10 seems to have tried (and to some extent failed) to deprecate Win16, ie. the API calls specific to Windows 3.1 and prior, but it's not comparable to Apple's deprecation of PowerPC.
New overlays (eg. MFC), new 'translations' (eg. every library portable to Windows), new frameworks (eg. .NET), but nothing excised.
Considering part of the reason I cling to C so tightly is because of Linux-and-co's long-lived tradition with it, this makes me much more comfortable writing code for Windows. If still a little horrified.
Mostly because Windows' development tradition is in C++, not C. The peppering of 'object' and 'component' everywhere is a hint. And C is largely an afterthought these days. (Often a contemptuous afterthought lending to my overall silence.) WinRT, the 'new' API going forward, doesn't officially support C at all, though you can still make it work.
Ah well. With the general allergy to the console I imagine it's a bit like coding for the Mac was back in the 90s. At any rate, nothing really changes for anyone else other than seeing a spare 'cygwin.dll' lying around; one of my priorities is giving people a single EXE or the like to click/drag/interact with, because that makes the most sense on Windows, and while Node's 'uhh run the engine and...' approach on Windows violates this, dynamic linking does not. (OSX is much better-suited for Node's... situation, when it comes to packaging and distributing Electron apps and such. Yes, I know you can 'compile' Node more tightly. It also takes an extra toolchain whereas compiling C is a built in functionality. Also, it's Node.)
I'm making a few smaller applications before I get back to the main meat. Notably, a little tool with sockets so that I can be pinged without being aggravated (TCP/IP code, JSON in C, tray applications...), and an egg timer that doesn't suck (timers, shaped windows, multithreading...). I have been pressed into using hourglass for the latter since my OS hop and ... by some quirk of my system it takes nearly 30 seconds to open every time. I don't dare speculate which quirk that is, knowing what I know now about Win32.
