Hacker News Reader

Comment by supernes | Hacker News Reader

I recently had an idea about an app and a clever way to hook it into fairly modern, user-facing parts of Windows and macOS (Search/Cortana and Spotlight, respectively.)

I did some feasibility research on Windows first, and very soon hit some ancient win32 interfaces I had to implement, used by parts of the shell that have existed since the earliest days, something I have no intention of wasting my time on.

I was under the impression that macOS would be much better, but was surprised to find that there's no public or documented API, just a 3rd party open source framework implemented as a hack that combines javascript and python somehow, but seems to get the job done.

This got me thinking that you need a serious amount of expertise to implement new experiences on modern operating systems, never mind crossing platforms. Puts the appeal of technologies like Electron that do platform integration for you in perspective.

View on HN

On Windows, you do need some effort if you have no idea what is going on, but it isn't like those systems were sloppily put together, there are some design ideas and you get used to them... eventually. But once you do, things more or less fall into place.

A biggest issue with working on older Windows APIs is that modern web-based MSDN documentation is simply awful and the best you can do is to find old MSDN CDs/DVDs that often contained more information than the site (especially articles), better organization and -especially- much faster interface (being local and all, but also the cdroms around late 90s / early 2000s were in CHM format are lightweight). And 99.999% of the documentation you'll find on these CDs will have the same text as the documentation (if it still there) on MSDN (and very often the same text that is on the much older WinHelp WIN32SDK.HLP files too).

Like most things Microsoft on desktop, everything went downhill since .NET people took over and decided to redo things their way (yes, .NET brought some nice things too, but it created an internal schism - before .NET became a thing, desktop tech in Windows was mostly coherent) and now history is repeated with UWP.

Totally agree. I worked for a while with pure Win32. Once you get the hang of it it’s quite consistent and pretty well thought out. Also agree about the documentation. Seems MS is determined to make it worse every year, break more links and provide less useful information. The old MSDN CDs were a piece of beauty.

Consistency?

Let’s start with strings...

- the standard null terminated single byte char C string

- the double wide null terminated C string required for dome frameworks - especially Windows CE

- the COM BSTR where the first two bytes are the length

- the ATL bstr_t

- CString that isn’t a null terminated C string

- of course the C++ string class. I’m not sure if this is ever used by the Win32 APIs

I’m sure I’m missing one.

TCHAR probably counts because, even though it's just a typedef for char or wchar_t, it has its own t-prefixed APIs and mental overhead of having to write code that can work with either character size.

If you count various flavors of UWP (C++/CX, C++/WinRT, WRL) you can add std::wstring and Platform::String^

Don't forget HSTRING, which Platform::String^ is built on. They added those two in Windows 8 because there was no one standard string type. (Not joking.)

UNICODE_STRING too - https://msdn.microsoft.com/en-us/windows/desktop/ff564879

So there is also the OEM_STRING and the ANSI_STRING

.NET and WPF are an abstraction of win32, I view it as a step in the right direction. How did .NET people cause everything to go downhill?

Especially WPF is not an abstraction of Win32. Maybe Winforms could be called that but certainly not any of the XAML dialects.

WPF is deeply integrated with Win32. For example it abstracts away the win32 message pump design. I'd call that an abstraction.

Yes, it abstracts it to the extent that it doesn't resemble Win32 anymore. It's something else.

I would have to agree. Win32 is immediate mode, while WPF is retained scene graph.

It's not an abstraction its a complete overhaul.

MFC is an abstraction to me.

As far as I know WPF is built on Direct whereas MFC and Winforms are based on Win32.

That's my understanding as well. Point spy at a WPF app and you see one top level HWND which is just hosting a DX context

The difference is that WinForms uses some of the actual higher-level UI widgets and layout system from Win32/USER, WPF just uses its message pump and other low-level windowing/IO routing mechanisms, and builds all its own bespoke composition, layout and controls on top of that.

WPF is a lot closer to an abstraction over Direct2D than Win32. If you use both of those APIs a lot, you start to realize they have a lot of classes with the same name that do the same thing.

I wonder if there is a real black market for bootleg MSDN cds from the early 2000s.

Reply on news.ycombinator.com