After Visual C++ 6. They broke a lot of the C++ IDE features and they weren’t as good as the prior versions (dialog editor etc) so for a long time we preferred staying on 6. I think if we could have the newer compilers but the snappiness of that UI many developers would be happy.
It’s also a product of the segmentation of the developer tools in Microsoft. The Windows team was responsible for the compiler rather than the Developer Tools team.
No, that's not really true. I was on the C++ compiler team from 1991 to 2006. When I first started, the DevTools team reported up through the Windows team, but never really felt a well-integrated part. We were never in the same building as the Windows team, for instance. I remember, probably 1992 or 1993, driving from building 4 where the compiler team lived to the Windows building (forget which one that was, maybe in the 12 to 15 block back then?) to get a copy of the Windows NT source on a hard drive. That's because I was a dev on the C++ compiler back-end team then (moved to the front-end in '95, IIRC), and compiling that source was a major test of the 32-bit compiler I was working on.
Don't remember when DevTools was re-orged out from under Windows, but I'm pretty sure it was by '95, and well before VC++ 6.
No, there were two devs working on the 68k Mac compiler, with ~10 devs on the x86 side (though both targets shared a lot of code and differed mainly in the late codegen and peephole optimization phases). I never worked on the 16-bit code; the 32-bit and later 64-bit x86 backend was a different codebase from the 16-bit stuff.
If I remember from poking around at the 16 bit version in that timeframe (1.52?) there was still an option to generate P-code and (this is now nearly thirty years ago) that was used by Excel to minimize code size for the segmented 16 bit systems.
Any idea how many devs are working at Microsoft on the C and C++ compilers these days? I've heard rumours that there's more on the Rust team and that C++ is taking a back seat.
No clue. I left as a full-time employee in 2007, did a few contractor gigs with various old teams of mine to help out, but that was done by 2013. I lost touch with how things were going internally after that.
The dialog editor is a good example of the damage that was done with the VS.NET transition. When they rewrote it to use the WinForms-based UI, they introduced a fundamental bug: the Z-order for picking was reversed so that clicking on a stack of controls selected the one on the bottom. Very annoying for controls like group controls intended to be stacked below other controls. Bug filed, WONTFIX'd, and it's still broken to this day.
No, overlapping sibling controls is absolutely supported in Win32. It has a defined Z-order for child controls along with functions to manage it:
> The system maintains the z-order in a single list. It adds windows to the z-order based on whether they are topmost windows, top-level windows, or child windows.
The WS_CLIPSIBLINGS window style is also explicitly for controlling cross-clipping of child windows during painting:
> Clips child windows relative to each other; that is, when a particular child window receives a WM_PAINT message, the WS_CLIPSIBLINGS style clips all other overlapping child windows out of the region of the child window to be updated.
Furthermore, group boxes and tab controls require overlapping child windows, because they are designed for the controls that visually appear within them to be sibling controls that are raised in Z-order. This is why the dialog editor's current behavior is broken, because the editor's picking behavior is opposite the drawing behavior and USER32's hit test order.
He wrote Programming Windows 3.1 which was the classic reference for Windows programming in the 90s and just known as ‘Petzold’. All Win16 and C. The managed languages are much later.
That means ios is not safe. Software that you don't control and was not written by end-users for end-users benefit, but was instead written by the same people who wrote the printer's firmware can send a print job from ios to the printer.
The printer doesn't care what physical connection or network protocol is used, including airprint, and in the case of ios, while you might be able to print some documents without using any software from HP, HP does still have a an "HP Smart" app (and probably others) for ios. Meaning that blocking the printer from the internet does not prevent the printer from receiving updates, and all of the closed-source platforms are the primary dangers as sources of update print jobs.
Technicall linux/bsd are not garanteed safe either.
It's possible for a native linux app to send the same kind of update, but just far less likely without the users knowledge or intent.
You have to go pretty far out of your way to install non-repo software from a printer manufacturers web site, and actively grant it permission to install and activate services that run on their own... And even if you did that, if such software even existed that was not well-behaved, the first time it did that to a linux user that didn't expect it, we would all find out about it and every google search on the topic of linux drivers for that printer would warn about the bad software.
Or just no one would ever actually bother even looking to try to install it in the first place simply because the normal open source drivers and apps work well and the manufacturers software is a crazy mess.
I had a Samsung color laser printer that actually had linux software provided by Samsung that I actually installed just to check it out. HOLY SHITBALLS it was terrible both outwardly just using it as a user and behind the scenes how it was written. Just crazy utter garbage all around. That software, since it wasn't open source, might do anything on it's own just like a Windows driver, including sending a printer update, but it was such junk, and so not-needed, that no linux user ever installs it, so it does no harm even though it exists and could.
I seem to remember on one of the special features on the DVDs that they needed to change to a lighter more comic style with Moore because of the reaction to the Vietnam War.
It’s not only that but it’s also that drivers could ship custom property pages in an accompanying DLL. All using property page / dialog box classic Win32 technology.
So unless you have a locked down device like a phone, you can’t magically port everything over to a new settings app without providing a path for your ISV / IHV ecosystem to migrate to on timelines that are sensible for the business. And ‘drivers’ consists of way more than hardware devices: database access drivers etc etc.
Part of me wonders if an AI model couldn’t just sandbox the old UI and inspect it, and then auto map to a new settings style AI.
