5 ms·
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, respec
by supernes 8y ago
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.
- Crinus 8y agoOn 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.
- maxxxxx 8y agoTotally 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.
- scarface74 8y agoConsistency? 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.
- cpeterso 8y agoTCHAR 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.
- Impossible 8y agoIf you count various flavors of UWP (C++/CX, C++/WinRT, WRL) you can add std::wstring and Platform::String^
- asveikau 8y agoDon'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.)
- xpaulbettsx 8y agoUNICODE_STRING too - https://msdn.microsoft.com/en-us/windows/desktop/ff564879 https://msdn.microsoft.com/en-us/windows/desktop/ff564879
- scarface74 8y agoSo there is also the OEM_STRING and the ANSI_STRING
- TravHatesMe 8y ago.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?
- maxxxxx 8y agoEspecially WPF is not an abstraction of Win32. Maybe Winforms could be called that but certainly not any of the XAML dialects.
- TravHatesMe 8y agoWPF is deeply integrated with Win32. For example it abstracts away the win32 message pump design. I'd call that an abstraction.
- maxxxxx 8y agoYes, it abstracts it to the extent that it doesn't resemble Win32 anymore. It's something else.
- jjaredsimpson 8y agoI 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.
- maxxxxx 8y agoAs far as I know WPF is built on Direct whereas MFC and Winforms are based on Win32.
- jjaredsimpson 8y agoThat'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
- vxNsr 8y agoI wonder if there is a real black market for bootleg MSDN cds from the early 2000s.