Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A visual history of Visual C++ (2017)

malsmith.net

Post reply on HN
Print view View original

21–30 of 53 posts

Re: A visual history of Visual C++ (2017)

#21

Post by agent327 »

Disposal8433 wrote: post #18
AdieuToLogic wrote: post #9

You know what this doesn't show? Visual C++ v4.2b generating an assignment operator which invoked the destructor of a returned object before assigning it to the lval. That was fun to figure out. :-/

I remember a bug in an old Visual C++ that would fill your RAM and swap (therefore hard drive) if you forgot a semicolon at the end of a class, like: class A { int a } int main(...) To fix that, you had to kill the compiler process.

Nice one... I seem to remember MSVC 5 having a switch that made all functions virtual - or am I confused with another compiler?

Re: A visual history of Visual C++ (2017)

#22

Post by lepicz »

philiplu wrote: post #15
keithnz wrote: post #11

It doesn't point out the massive productivity boost of Visual C++ 6, IntelliSense (ie, autocomplete). This saved so much time from having to look up documentation.

I worked on that! I was a dev on the team that built the first IntelliSense engine for C++. It’s a miracle it worked at all. It was based on a hacked-up version of the C++ front-end, but when it inevitably hit errors attempting a single-pass parse of the current source, it would silently bull its way through and try not to get too screwed up. Doing that in the presence of templates was not a good time. But with the R…

heh, sorry, but intellisense was the first thing we (in a game studio) turned off immeadiately after install (by deleting the dll as there was no other way) because it was unacceptable resource hog. this was around VS 2003/2005/2008.

visual assist x worked better.

Re: A visual history of Visual C++ (2017)

#23

Post by daemin »

philiplu wrote: post #14
becurious wrote: post #12

Earlier quoted context omitted.

Did you ever work on the cross edition that would compile Windows apps for the Mac? I think that was a version 4 fork that never got another version.

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.

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.

Re: A visual history of Visual C++ (2017)

#24

Post by philiplu »

daemin wrote: post #23
philiplu wrote: post #14

Earlier quoted context omitted.

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.

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.

Re: A visual history of Visual C++ (2017)

#25

Post by zerr »

philiplu wrote: post #15
keithnz wrote: post #11

It doesn't point out the massive productivity boost of Visual C++ 6, IntelliSense (ie, autocomplete). This saved so much time from having to look up documentation.

I worked on that! I was a dev on the team that built the first IntelliSense engine for C++. It’s a miracle it worked at all. It was based on a hacked-up version of the C++ front-end, but when it inevitably hit errors attempting a single-pass parse of the current source, it would silently bull its way through and try not to get too screwed up. Doing that in the presence of templates was not a good time. But with the R…

No offense but the first thing I used to do after MSVC installation was the installation of Visual Assist :)

Re: A visual history of Visual C++ (2017)

#26

Post by zerr »

(Not so) funny that there was nothing "visual" in Visual C++. The dialog resource editor was a joke. I remember how I was relieved when I discovered Borland C++Builder, so I didn't have to switch to Delphi for Windows software development.

Re: A visual history of Visual C++ (2017)

#27

Post by zerr »

ack_complete wrote: post #8
becurious wrote: post #6

Earlier quoted context omitted.

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 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 brok…

Afaik Win32 API explicitly states that overlapping sibling windows/controls is not supported.

Re: A visual history of Visual C++ (2017)

#28

Post by jasode »

birn559 wrote: post #20

When / How did versioning enter versioning the awkward state we have today? There is cl.exe, MSBuild and build chain at the very least (now at work computer at the moment, pretty sure I am wrong with the making here) with versioning that is close enough to each other to be confusing and related to each other in word ways. Naming itself also feels confusing to me. Documentation also only helps when you already have a…

>When / How did versioning enter versioning the awkward state we have today? There is cl.exe, MSBuild and build chain

The multiple confusing version numbers are caused by each software component (e.g. "cl.exe" vs "msbuild.exe" vs IDE "devenv.exe" vs platform toolkit SDK) evolving separately over decades. (https://en.wikipedia.org/wiki/Microsoft_Visual_C%2B%2B#Inter...)

E.g. Today's "cl.exe" at version 19.x goes all the way back to 1983 with Microsoft C 1.0 for MS-DOS. Just a text-based command line compiler with no C++, no GUI, no "Studio", etc. 43 years of the core compiler going from 1.x to 19.x. The Visual IDE component of VC++ version 17.x has a different version history going back to 1993 with 1.0. Microsoft C# also has different version numbers of C# language version vs .NET version vs CLR version, etc.

It's analogous to Linux world of different tools with different version numbers. GCC is 15.x, glibc is 2.4, make is 4.4, etc. If you include a "visual GUI IDE" like Jetbrains CLion, that's yet another different version (252.x) that doesn't match any of the others.

Microsoft could hypothetically "synchronize/unify" all version numbers for all disparate products to be a single number ... akin to Apple using version "26" to synchronize Xcode with iOS, etc by introducing large numerical gaps like v18 --> v26. That's probably not going to happen. Likewise, different groups at GNU are not going to agree to synchronize all version numbers such that next release will be GCC 20.0, glibc 20.0, and make 20.0.

Re: A visual history of Visual C++ (2017)

#29

Post by LordN00b »

aaronbrethorst wrote: post #10
copper_think wrote: post #2

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…

If memory serves, it was Visual InterDev that won, actually. The VID IDE was the forerunner to Visual Studio.NET 2002, which was the first unified Visual Studio IDE. n.b. I worked on the Visual Studio Core team, which maintained devenv.exe, among other things, from 2003-2007'ish.

Visual InterDev was the first IDE I ever used outside of notepad. It was bundled in with one Microsofts early webediting tools with office (97/200)....but not FrontPage. I thought I was touching the future, it was so amazing! I really don't remember much about other than the impression that it left on me.
Post reply on HN