Visual C++ version 6 woes...
I still am using Visual C++ 6 to develop a few things. Mostly this is because I had a laptop with "only" 384 Meg, that was being brought to its knees running IIS and SQLServer - let alone .Net studio.
C++ 6 has been fine for me. I actually prefer the way the debugger isn't tied to the script debugger, so you can debug both assembler and script in a process at the same time - something lacking from .net 2003.
But. VC6 has lots of holes in its libraries. And two days ago I hit on a particularly insidious looking one: _bstr_t uses the stack to allocate its strings. I haven't investigated fully, but passing a big string to the constructor of _bstr_t seems to cause the stack to go pop, under certain circumstances. Now lots of people use this, so I wonder how many people have inadvertantly created vulnerabilities in their code by using this mechanism? Why the hell it doesn't use the OS SysAllocStr functions I do not know.
Debugging these type of errors is very time consuming, so instead I am going to take the opportunity to move the code base up to 2003, which hopefully will give me more joy on this front. The whole experience is enough to make one terrified of using MS libraries for anything...
C++ 6 has been fine for me. I actually prefer the way the debugger isn't tied to the script debugger, so you can debug both assembler and script in a process at the same time - something lacking from .net 2003.
But. VC6 has lots of holes in its libraries. And two days ago I hit on a particularly insidious looking one: _bstr_t uses the stack to allocate its strings. I haven't investigated fully, but passing a big string to the constructor of _bstr_t seems to cause the stack to go pop, under certain circumstances. Now lots of people use this, so I wonder how many people have inadvertantly created vulnerabilities in their code by using this mechanism? Why the hell it doesn't use the OS SysAllocStr functions I do not know.
Debugging these type of errors is very time consuming, so instead I am going to take the opportunity to move the code base up to 2003, which hopefully will give me more joy on this front. The whole experience is enough to make one terrified of using MS libraries for anything...
Comments