One thing not mentioned is that Visual C++ and Visual Basic historically were separate IDEs with separate codebases. When the time came to unify them, only one of them could continue on. My understanding is that Visual Basic won, and that today's Visual Studio IDE (devenv.exe, msenv.dll, etc.) is the continuation of that VB codebase.
I don't actually know in which release that transition happened. But since there's a screenshot of each version in the article, presumably that transition is visually documented...
The author mentions the screen being corrupted when a DOS prompt is opened in windowed mode. This can happen because the DOS prompt runs in a separate VM (in V86 mode), and makes calls into the VGA ROM BIOS via INT 10h. The VGA ROM BIOS on this machine is probably a wrapper over VBE; that is, it probably contains IN and OUT instructions that talk to the VBE I/O ports, 0x1CE and 0x1CF. These reads and writes from the DOS VM will, by default, be allowed to reach the physical hardware if they are not virtualized by the VMM.
This is a common problem that authors of Windows 3.x/9x display drivers had to handle, although the specific I/O port numbers to be virtualized vary by graphics adapter. There are samples in the Win95 DDK that show how to use the VMM services Install_IO_Handler and Enable/Disable_Global_Trapping to set up I/O port traps, and VDD_Get_VM_Info from within the trap handler to determine the VM that currently owns the CRTC. This allows the trap handler to reach a decision about whether to allow an I/O to reach the hardware, or to virtualize the access in some way. A good virtualization policy to start with is probably just to drop any writes from non-CRTC-owner VMs. Any additional needed complexity can be added from there.
Maybe one day you'll be rich too, and can work tirelessly to avoid paying your fair share to the government. But I kind of doubt it, because you don't know the difference between "sites" and "sights."
So, it's just enantiomerically pure S-ketamine - not really a new drug discovery. The drug is already around as an anesthetic but it is almost finished with the FDA's approval process for treatment-resistant depression. When used as an anesthetic it is administered intravenously, but the anti-depressant formulation is a nasal spray. Cool! That definitely makes it more accessible.
I wonder if J&J got a patent on S-ketamine? The patent system is often abused this way. First you sell the racemic mixture, then when that patent is about to expire, you start selling a new product that is just the active enantiomer. And you can tell customers that it's new and improved: that you only need to take half as much! See Prilosec/Nexium, Celexa/Lexapro, etc.
Although, maybe it's difficult to manufacture just the one enantiomer, at scale?
What is the value that private equity and/or VC are adding to dermatology? I guess what I'm asking is, why would the physicians be interested in sharing some portion of their income with these non-physicians?
Medicine, like other guild professions like law, dentistry, and accounting, is an enterprise which seems to naturally fit the partnership model instead.
Application Verifier is a feature of Windows for developers to use to check program correctness. Bruce says he turned on Full Page Heap, which makes every allocation go on a separate page, and tries to line it up so that the next page is not readable or writable. The idea is, if you go past the end of your memory allocation, the CPU raises a protection fault, and you catch the memory corruption bug at its source. Application Verifier can also do other things, like raise an error if your program ever passes an invalid HANDLE to a Windows system call.
Application Verifier is turned on by process name (i.e. "explorer.exe"). I think most of the time, developers turn on an Application Verifier feature, start just one process by that name, and then verify. But Bruce turned it on for a short-lived process that runs in a large build. So it runs thousands of times, and he hit this problem. It sounds like a great thing to fix, but I don't think it affects most developers using Application Verifier, and it definitely doesn't affect 'normal people' who are just using Windows on their laptop or desktop.
At Microsoft the compiler team (Visual C++) and the Windows team are joined at the hip. I'm sure the same was true at Sun. This can lead to good decisions about undefined behavior that I hope would make Linus smile.
I recently learned of one such good engineering decision (I hope I'm remembering it correctly). Let's say you have a struct with an int32 and a byte in it. That's 5 bytes, right? But the platform alignment is a multiple of 4 bytes, so there's 3 bytes of padding (sizeof the struct is 8 bytes). If we stack-allocate an array of 11 of these and zero-initialize with = { 0 }, what would you expect to see in memory after initialization?
It turns out the answer was that the first element of the array would have its 5 bytes zeroed, but the 3 bytes of padding would be left uninitialized. Then, the remaining 10 elements of the array would be zeroed with a memset that actually zeroed all 80 remaining bytes. It sounds weird but this is a legal thing to do from the standard's perspective. All they're obligated to zero out are the non-padding bytes. This UB was leading to disclosure of little bits of kernel memory back into user mode because Windows engineers assumed that = { 0 } was the same as leaving the variable uninitialized and then memsetting the whole thing to zero. Nope!
The compiler team fixed this by always zeroing out padding too. Problem solved. There are some cases where it's not quite as fast. But it's the right engineering decision by the compiler team for their customers, both internal and external.
Just finished benchmarking this for a key workload in our build process. It's 3% faster than Node 8.x for us. But node-chakracore (the Microsoft runtime) 8.9.4 was 11% faster -- we are considering switching to that.
Man, I really wouldn't. My understanding is that of the people who present to the emergency department with chest pain, something like a third of them have been using cocaine. It causes Real Problems.
You're both right. Yes, it's WPF, and there are lots of parts written in C#. But the parent is right -- Visual Studio is C++ using COM and Win32 at its core, going back all the way to the Visual Basic IDE that shipped as part of Visual Studio 6. It would be a very difficult port to Mac, Linux, etc. As of this writing there is even no 64-bit version for Windows (although that's just a matter of spending the time and money to do it.)
The brand name has been re-used for other software. Visual Studio for Mac is Xamarin. Visual Studio Code is on the Electron platform.
My recollection is that Dan was working at Microsoft during "Third real job (2015-2017)." (He has a couple of posts in this timeframe where he refers vaguely to his employer. "Hiring Lemons" is one.)
I would be interested to know what teams Dan worked on while he was at Microsoft. He says that team #1 couldn't build their source code on most days, and that while team #2 was better, they still often had broken builds in origin/master.
I don't actually know in which release that transition happened. But since there's a screenshot of each version in the article, presumably that transition is visually documented...