Running Visual Studio 6 C++ in Windows 8.1

Question

I recently migrated my system to windows 8.1. Unfortunatly like some others, I am not able to start Visual Studio 6 anymore. The software is crashing at startup (splash screen).

I know there are some workaround, to be able to compile with vc6 in newer IDEs, but this is not working for me, since I have to compile a huge number of project and I cannot afford of modifying all the project files 1 by 1...

I already see the answer coming: that vc6 is so old, and not supported and so on... I am aware about all that! But migrating a lot of code can take a long time and for now we have no other solution!

Since vc6 was running just fine on Windows 8, I am sure that with some small trick we can manage to get it running under 8.1, but I haven't figured out how yet!

Did anyone manage to start Visual Studio 6 on Windows 8.1?

Answer 1

I find a simple way to solve the problem！

1. Look for "MSDEV.EXE" in this path:"C:\Program Files\vc6\Common\MSDev98\Bin".
2. Rename "MSDEV.EXE" as "MSDEV3.EXE".
3. Use compatible mode "XP SP2 or SP3".
4. Run MSDEV3.EXE, report error,rerun again and you will succeed!
5. If failed, rename MSDEV.EXE as other names and use compatible mode will lead to succeed.

Answer 2

I have VS6 running on Windows 8.1 fine after I found these helpful instructions:

http://blog.wavosaur.com/run-visual-c-6-on-windows-8/

It is unusual indeed that Windows 8 retained compatibility for VS6 without this additional work, and yet Windows 8.1 does not. I hope this helps!

Answer 3

I found this: http://www.wavosaur.com/forum/run%20vc6%20with%20windows%208.1%20%28if%20msdev.exe%20crashes%29-t1362.html

I haven't tested it yet, but I will asap and let you know !

Answer 4

I have been successful with another method (similar to the method of @szc982):

1. Go to "C:\Program Files (x86)\Microsoft Visual Studio\Common\MSDev98\Bin"
2. Rename "MSDEV.exe" into "MSDEV-S.exe" (or any other name)
3. Right-Click on "MSDEV-S.exe" > Properties > Compatibility > Change Settings for all users
4. Check "Disable display scaling on high DPI settings" and click on "OK"
5. Go to "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Visual C++ 6.0"
6. Right-Click on the shortcut "Microsoft Visual C++ 6.0" and change the target to "MSDEV-S.exe"

Answer 5

I had a critical need to use VS 6 to continue development of a large MFC application on my Win8 box after upgrading to 8.1. I followed advice from here and elsewhere to copy MSDEV.EXE into a file with a different name (let's call it MSDEVX.EXE) and to change the compatibility settings for the new program to Win 8.0. Unfortunately, the app ran very slowly as a debuggee whenever it used the HeapXxx APIs or an CHttpFile object. I concluded that the problem was the "Fault Tolerant Heap" shim. I cast about wildly for a way to get rid of the FTH shim, and I eventually found one:

I created another copy of MSDEV.EXE -- let's call it MSDEVQ.EXE. I installed the Application Compatibility Manager and followed the instructions to create a custom database with an Application Fix for MSDEVQ.EXE. To create the settings, you'd think you could just copy the MSWIN8 settings and then subtract out the FTH shim. Alas, there is a bug that prevents you from saving the resulting database. Microsoft arrogantly says it won't fix this bug because you should never need to copy compatibility settings. Fine, so I copied the shims one by one, leaving out the FTH shim that's part of MSWIN8. I saved and installed the resulting .sdb file. Voila! No more FTH shim, and I'm back to being able to debug effectively.

Answer 6

1. Go to "C:\Program Files (x86)\Microsoft Visual Studio\Common\MSDev98\Bin"
2. Rename MSDEV.exe to MSDEV-S.exe (or any other name) - first try the name mentioned before; if it does not work then use MSDEV3-S.exe or any other name like that.
3. Go to search by moving your mouse to the right down edge of your screen and type this C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Microsoft Visual C++ 6.0
4. Open it and go to Common\MSDev98\Bin and run MSDEV3-S.exe . If that causes an error, then rerun again and hopefully you will succeed!

This is similar to what Francios has posted but you do not need to change the target.

Answer 7

Another simple solution:

1. Make a copy of MSDEV.EXE to anything ( for example MSDEV_XP.EXE )
2. Set the compatibility of the copy MSDEV_XP.EXE to XP
3. Launch the renamed copy MSDEV_XP.EXE instead.

Explanation:

Microsoft installs two executables, MSDEV.EXE and MSDEV.COM , one of which can be made to run in recent WINDOWS versions. If you launch MSDEV in a shell or script ( a makefile for example ), you don't want to launch the COM instead of the EXE , and making a copy with a different name solves that. (Also, if you leave the two files Microsoft installed as is, you can be sure you're not breaking any existing functionality)

This solved my problem when I was building with a make file which I changed to call my copy that had been changed to XP compatibility. Note that I did need to use the original MSDEV.EXE in some cases, so it's good to have both.

Answer 8

Run and follow instructions..并按照说明进行操作。

For , type: ，键入：

ren "C:\Program Files (x86)\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV.EXE" MSDEV3.EXE

For , type: ，键入：

ren "C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV.EXE" MSDEV3.EXE

Now go to your desktop and right click in any empty space then choose -> , and then if you have set the location to: C:\Program Files (x86)\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV3.EXE -> ，然后如果您有将位置设置为： C:\Program Files (x86)\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV3.EXE

or if you have set it to: C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV3.EXE，请将其设置为： C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin\MSDEV3.EXE

Answer 9

The Fix

1. Delete the "DEVRES.PKG" file, but you will lose the resource editor.

or

2. Patch the buffer overflow in "DEVRES.PKG" with a hex editor.

// Microsoft Visual Studio 6.0
// Crash Fix (Buffer Overflow)
//
// Module: Resource Editor
// DEVRES.PKG v6.0.8168.0 - 17.6.1998 0:00
//
// Original SHA1 : 59afd55f13310dcdbfff777fe6f4c7d0a8191a82
// Fixed SHA1    : 00bb8497adca2467eaba022a34bf4fdafd3d7c6c
// 

--------


0x00004518 / 0x50403518:

FF 25 74 1A 40 50    ; jmp     ds:__imp_??2@YAPAXI@Z ; operator new(uint)
->
E9 8F 0F 10 00 90    ; jmp     0001054AC ; nop

--------


0x001054AC / 0x505044AC:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
->
55 89 E5 8B 45 08 B9 02 00 00 00 F7 E1 50 FF 15 74 1A 40 50 59 89 EC 5D C3

55                      push   ebp
89 E5                   mov    ebp,esp
8B 45 08                mov    eax,DWORD PTR [ebp+0x8]
B9 02 00 00 00          mov    ecx,0x2
F7 E1                   mul    ecx
50                      push   eax
FF 15 74 1A 40 50       call   DWORD PTR ds:0x50401a74
59                      pop    ecx
89 EC                   mov    esp,ebp
5D                      pop    ebp
C3                      ret 

--------


0x000001E8:

AC 34 10 00
->
DC 34 10 00          ; increase .text section virtual size by 30 bytes


--------


0x00000140:

29 8D 19 00
->
77 FD 17 00          ; fix PE checksum


--------

Explanation

The real reason why Visual Studio 6 crashes on new hardware has actually nothing to do with your OS, it works just fine in later Windows versions too but there are multiple buffer overflows in the resource editor module (DEVRES.PKG) which have seemingly gone unnoticed all these years.

The resource editor module has multiple calls to the C++ new[] operator using values that are too small without doing bound checking. But because of the way memory allocation and alignment works, it just always got "lucky" and did not crash, as the pointer memory block had more "extra" space than requested and then it wasn't overwritten or accessed by anything else before the operation was completed.

What has changed since then, is every part of your computer has become a lot faster; processor, memory, I/O, the works. There were no 16 core 32 thread processors in the early 2000s, nor 5000MB/s SSDs or fast memory. So now when running on a modern processor, what happens is that the memory which resource editor didn't properly allocate, gets overwritten by another thread while it's still being used (yes, VS6 is multithreaded, even if very lightly so).

That's also the reason why all sorts of different bags of tricks work to "fix" it, what they have in common is that they change the execution path (by slowing processing down and/or changing how memory is allocated/aligned) slightly so by luck you pass the buffer overflow without crashing. The compatibility layer slows it down, as does running it in a VM. Running it from a HDD instead of SSD can make the difference, changing folders, restarting the computer, or even something like running a 4K video stream in the background.

I know it's 2022 but I don't think Visual Studio 6 is any less useful today than it ever was. The resource editor is still the best comparing to all the new editions, and even if I code something in VS2019 I still use the editor in VC6 to design the dialogs. Also if you want to just code a quick tool which will work in any Windows version without any redistributables, VC6 is still the pick.

In any case, there are two ways to fix the crash for good.