14.
 
Re: Morning Mobilization
Mar 6, 2017, 18:03
14.
Re: Morning Mobilization Mar 6, 2017, 18:03
Mar 6, 2017, 18:03
 
A few thoughts:

History Lesson

Win32 is the combined systems/applications programming interface developed for Windows 95. I've not studied the Windows 9x kernel in any depth (no longer relevant) but my understanding is that it was a hugely improved version of the MS-DOS kernel, with things like true multiprogramming (i.e. multitasking), virtual address spaces and memory management, etc. but was nevertheless still built on the (shaky) foundation of MS-DOS. Individual applications no longer took the whole system down, but individual drivers sure did.

Parallel with the development of Win9x, Microsoft developed the Windows NT kernel, a fresh start, influenced by some of DEC's operating systems for their VAX series of computers (NT and some of the VAX OSes shared a lead developer). By the time MS was ready to drop the Win9x kernel and completely switch to the NT kernel (with the release of Windows XP), the Win9x line of operating systems had been hugely commercially successful, and not having backwards compatibility would have killed any chance of XP being adopted. Accordingly, the Win32.dll became a wrapper library for NT system libraries and NT kernel sys calls, so as to maintain backwards compatibility. Despite attempts to gradually replace Win32 with things like the .NET Framework, Win32 has stubbornly stuck around, and will likely never go away.

Win32 as an API

Win32 is a colossal piece of shit from a software engineering perspective.

Functions with 14 parameters are not uncommon. Some functions trap to kernel mode, i.e. are sys calls and incur additional performance overhead, while others are handled entirely in user space, yet which are which is not fully documented and changes from version to version of Windows. Functions rarely do one thing and do it well and simply (perhaps THE essential principle of software engineering), but instead do many things through as complex a mechanism as you can imagine.

The API operates at mixed levels of abstraction, handling everything from process and thread creation and management, memory management, and low-level I/O, to GUI programming, windows management, and user event handling. Compare this with Linux or macOS, where low-level sys calls are provided by the Linux and Mach kernels (respectively), and various APIs are layered on top in increasing levels of abstraction, so that systems programmers can use one API to deal with systems programming concerns and end user application programmers can use another API, further up the stack, (like the macOS/iOS Cocoa/Cocoa Touch framework) to deal with application programmer concerns.

Win32 sucks, but we're stuck with it.

UWP as an API

I don't have any direct experience with .NET or UWP, so I can't comment on it's quality as an API, but it is difficult for me to imagine it being worse than Win32. To the extent that UWP improves the programmer's experience developing for Windows, then it might also means Windows development might be something I'd be willing to consider (as opposed to being an impetus for suicide).

UWP as a Walled Garden

Microsoft would be fucking retarded to let UWP become the basis of building a walled garden. Likewise, they would be committing suicide if they dropped Win32: there's simply too much software, both legacy and current, running on it. Microsoft has been acting smarter as of late, so there's reason to hope that UWP simply becomes a better end-user applications level API that makes Windows software development more palatable to the engineers tasked with doing it. On the other hand, Microsoft's history gives plenty of precedent for assuming that they'll do the stupid, shoot-self-in-the-foot thing.
Date
Subject
Author
1.
Mar 5, 2017Mar 5 2017
2.
Mar 5, 2017Mar 5 2017
3.
Mar 5, 2017Mar 5 2017
5.
Mar 5, 2017Mar 5 2017
4.
Mar 5, 2017Mar 5 2017
6.
Mar 5, 2017Mar 5 2017
7.
Mar 6, 2017Mar 6 2017
9.
Mar 6, 2017Mar 6 2017
10.
Mar 6, 2017Mar 6 2017
12.
Mar 6, 2017Mar 6 2017
11.
Mar 6, 2017Mar 6 2017
13.
Mar 6, 2017Mar 6 2017
 14.
Mar 6, 2017Mar 6 2017
   Re: Morning Mobilization
15.
Mar 8, 2017Mar 8 2017
8.
Mar 6, 2017Mar 6 2017