Microsoft Visual Studio 2008 was released late last year.
According to http://msdn2.microsoft.com/en-us/library/bb531344.aspx, Windows 9x is no longer a supported target platform:

The Windows 95, Windows 98, Windows ME, and Windows NT platforms are no longer supported. These operating systems have been removed from the list of targeted platforms.

The typical message upon running a VS2008 compiled application that uses 0x0500 in the WINVER macro is:
(For more information on WINVER macro see: http://msdn2.microsoft.com/en-us/library/aa383745.aspx)

Error Starting Program
The [full path of executable] file
expects a newer version of Windows.
Upgrade your Windows version.

Following this is:

[full path of executable]

A device attached to the system is not functioning.

This second information box would appear without the first if WINVER macro was still 0x0400 in a re-compiled source.
Either way, it no gonna run...

One person has determined that the Win32 API call GetSystemWindowsDirectoryW in KERNEL32.DLL was being referred to even with a simple application. See http://forums.microsoft.com/MSDN/ShowPost....93&SiteID=1

Maybe this is where a KernelEx solution could be useful.

This spells the end of new software for Windows 9x since most software developer for the Windows platform code in Microsoft C++ under Microsoft Visual Studio.
Windows APIs are taylored for C++ calling conventions and data types.
I personally code entirely using Microsoft Macro Assembler (MASM) which supports high level syntax and C++ conventions.
Contrary to popular belief, MASM is not just for writing modules to plug into C++.
It can be used to write an entire PE EXE, DLL, and so on. See here for more information: http://www.masm32.com
MASM version 8.00 that comes with Visual Studio 2005 still supports Windows 9x.

Has anyone looked into this problem?

Visual Studio 2005 was already the end for targeting Windows 95, actually. Compiled programs would look for an unsupported API because of the runtime. You could recompile it to not do this, though.

I had heard that.
The problem with VS2008 is that you cannot just change compile options to get it working...
It simply will not work in Windows 9x.
It would be good to get some heads together over this one with the purpose of finding some kind of workaround for VS2008 compiled software.
As mentioned previously, maybe some concept like the way KernelEx operates by expanding the Windows 9x API set.
Even if those API functions are 'simulated' with close 9x functions or simply returning a successful status if applicable.

Neither could you with Visual Studio 2005. You had to recompile the actual C++ runtime!

Maybe then, this topic should be called Visual Studio 2008 and Visual Studio 2005 and Windows 9x...
In that case, KernelEx may already solve some VS2005 problems...
If I had time, I would do some work with the KernelEx source...
Time, time, time, never enough!

Can anyone post source + output of some short program generated by VS2008 that is not working on 9x?

Hey Xeno86,
It's great to see you around!
See Offler's topic here: http://www.msfn.org/board/Vcredist-x86-t112725.html
He has identified three post-9x API calls being made to KERNEL32.DLL from VS2008 library DLLs.
Also there is Windows version checking happening.

I ran into a similar problem. See my post at VS 2008 and NT 4.0 (if the link doesn't work, search Google groups for "VS 2008 and NT 4.0").

I'm not sure if that helps you, but it worked for me. Not an elegant solution, but it does the trick (since that post, I do a post build step and modify the exe directly).

So, then, you've found another example of a downversion patch that works, this time on a PE file...
Awesome, jerichar99!
And welcome to Win 9x/ME forum!

Hello!



Thanks for great info. BTW, here is shorter link:

http://groups.google.com/group/Visual-Studio-NET-2005/browse_thread/thread/4fa74dafe3eb6ef5/

Regards, Roman

Would be nice if someone could make a patcher to "fix" files compiled in vc2008 to work on win98.

BTW, you can correct the checksum by using PEChksum, a small command-line app found as part of the freeware PESuite (info) (download link). HTH

This post has been edited by dencorso: Apr 8 2008, 09:04 PM

i have to learn C++ for my next job so i tried to install VS C++ 2005 and 2008. no installation was sucessful but...

KEX 0.3.3e applied to passthought the "requires newer version of windows"
vcsetup.exe of v2008 extracted with winrar.

Setup.exe missing exports:

kernel32.dll > HeapSetInformation
shell32.dll > SHCreateDirectoryExW
ole32.dll > CoWaitForMultipleHandlers
apphelp.dll > file missing (i try to add it manually)
userenv.dll > ExpandEnvironmentStringForUserW
Shell32.dll > SHBindToParent
advapi32.dll > InitiateSystemShutdownExW
secur32.dll > GetComputerObjectNameW

i believe that packages created directly by MS will be good source of information for us when it comes to identification of problem with exports.

This post has been edited by Offler: Apr 24 2008, 03:57 AM

What about Dev-C++?

thx. i will try it but i just wanted to post some missing exports from visual studio installer. M$ has all the dlls bound together so they are using them more as other programs.

Why not go back somewhat further and install Microsoft Visual Studio 6.0, which is known to work OK (I do use it) or even MS VS 2003, which some say does work? You'll learn C++ just the same, and won't have to worry about compatibility issues, 9x/ME- wise.

There are actually some patches, but here is what I think may be a better approach:

Legacy Extender for Visual Studio 2005/2008 (www.legacyextender.com)

Visual Studio references not only functions which do not exist in old Windows, but also some functions which exist, but which do not work (like Unicode functions in Windows 95). Legacy Extender includes a linkable library which takes care about all of these. The library approach also has the benefit of being compatible with code optimization. Post-build patches are not.

The second thing that Legacy Extender does is like EditVersion.exe (once provided by Microsoft): it has a command line tool to edit the subsystem version (Visual Studio writes 5.0, but you want it to be 4.0 to run on systems older than Windows 2000). Unlike some patches it also recalculates the checksum. It's not true that the checksum is not checked by Windows, it is necessary to be correct for some drivers and boot DLLs, and you never know if Microsoft or some antivirus software decide to be more strict against binaries with bad checksums in the future.

It would be great if they could release the source code for the APIs that they have created replacements for.

Seeing that this thread has been revived, now is a good time to throw some information on the table ...

Some of the most important utilities for Win9x sadly went toe-up several months ago when the author began compiling with Visual Studio 2008. Those utilities of course are the excellent System Internals applications: Process Explorer, AutoRuns and no doubt everything that Mark Russinovich (System Internals / Microsoft) gets around to updating.

Folks can look back to May 28, 2008 to follow events as they happened on this System Internals thread: Process Explorer v11.12 on Windows 9x/Me.

The discussion includes links which eventually get you to the next pertinent System Internals thread: EXEs created by VisualStudio2008 vs Win4.0. There, member steelbytes has reported some success in patching already compiled apps and also recompiling differently. He directs us to www.SteelBytes.com with specific code examples here.

The very latest development appears to be this LegacyExtender announced by the same member takeos that appears two posts above me here. While he/she sounds very confident in their approach, they seemed to have left out describing what if anything this will cost, and to whom? I would like to second the motion by BenoitRen as to what is getting replaced? It seems to me that *either* individual developers using VS2008 would be their 'customers' and manually tweak their installations (like we did back in the day with Curses, etc) or Microsoft itself would be their sole customer and incorporate this idea into VS2008 distributions, effectively restoring backwards compatibility defeating their obvious planned obsolescence. @takeos, can you shine some light on this? Please correct my mis-understandings. No flames intended, just asking!

If we consider the KernelEx developments (someone please ping them), we have three distinct avenues to keeping this Operating System alive and healthy at least for a while. Things do appear bleaker now, as I do not see folks like Mark Russinovich throwing out VS2008 for VS6 or later, and its doubtful he'd do us a favor by LegacyExtending his installation.

But I pray I am wrong!

Would something like $29.95 (individual developer license) be too much in your opinion? Some corporate developers might not even take it seriously at that price, while for others anything more than free would be too expensive. I exchanged ideas about the possible pricing. A small price would still give customers technical support and updates, i.e. if new functions emerge, they would likely be added to the library, etc.

Legacy Extender is not as vast as KernelEx. It focuses on what Visual Studio adds or breaks that the developer did not want in the first place. If the developer used some other XP-only functions on purpose, Legacy Extender will not help much. On the other hand, Legacy Extender is great if you already have a "legacy" project, and simply want to update the compiler, and you thought the only way was to run two different versions of Visual Studio.

I doubt that Microsoft would be interested (as a customer), because they have demonstrated that they do not care about legacy compatibility. To the contrary, it seemed to me that they introduced or at least supported incompatibility on purpose. Do you remember how Visual Studio 2005 became incompatible with Windows 95? At the time it did not really break much. It would not have taken more than a few hours of work for Microsoft to retain compatibility by just not using certain functions. Lots of programmers had proposed solutions, patches, etc. I proposed one to Microsoft myself after I filed a bug report (I thought it was a bug!), they filed the "bug" as something like "by design" and closed the case!

As for whether it works or not, it's currently being tested in public. Anyone can access it. You are free to decide for yourself, provide feedback, etc.

Just my two cents!