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

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.

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!

I did get around to making a patcher for compiled code that works for me ExeVersion
it does have some current limitations - eg, only release mode without function level linking. but that's just fine for what I need :-)

@takeos, thanks for that information. I was just trying to understand these various strategies to restoring backwards compatibility to apps that have no valid reason for failing to execute under Win9x. Both you and steelbytes are clearly on the good guys team, standing against these unnecessary winds of change.



Price sounds reasonable to me and I wish you much success. Speaking only for myself, I have yet to get Visual Studio 2008 but have almost everything prior, and will likely not use anything beyond VS6 personally because of all the time spent tweaking the libraries, options, editors and tools. Should that change I will no doubt grab your add-in.



Fully agree. This is certifiable planned obsolescence. I hope you are a MSDN member and figure out a way to publicize within the community. I find that the coders there, even Microsoft employees have much more sense than the suits who are making these stupid decisions.

I also hope that you can get Mark at System Internals to at least consider trying it. We can certainly survive on Win9x with older versions of AutoRuns (the startup areas are well-known), but Process Explorer is a definite loss. IMHO, he should compile that one for both platforms. It might help if other interested Win9x users would Contact Mark Russinovich with their suggestions.

Oh, you may want to look at a very important sticky thread here Last Versions of Software for Windows 98SE, + Current Software Still Supported. You might view this is as a potential goldmine of clients, well at least those that use Visual Studio. Maybe even the FireFox problem might be of interest to you.

To avoid hijacking this thread further, I'll eventually start a new one here that completely inventories the various System Internal utilities that still work in Win9x and those that have been recently euthanized by Visual Studio 2008. That would be a good place to chronicle any successes with steelbytes patcher against the compiled files.

Hi, all! If anybody need it for some reasons (i don't know for why, i made it just for fun) then i have repacked distributive of "Visual C++ 2008 Redistributable Package" for 9x only with deinstalling ability - http://ifolder.ru/5057911

And i have also three unofficial packs for Visual C++ 7.x Runtimes made in accordance to vcredist.exe (VC++6.0RP)

1. http://ifolder.ru/13373894 Unofficial Visual C++ 7.0 SP1 Redistribution Pack for Windows 95-Vista
2. http://ifolder.ru/13373908 Unofficial Visual C++ 7.1 SP1 Redistribution Pack for Windows 95-Vista
3. http://ifolder.ru/13373471 Unofficial Visual C++ 7.x SP1 Redistribution Pack for Windows 95-Vista (7.0 + 7.1 in-one)

Note: installation totally quiet, without any dialogs (like in vcredist.exe) and begins right after start

All packs are working and tested on all specified OS's (95-Vista) but i don't give any warranties for it, use at your own risk.

Thanks for attention and sorry for my bad english.

Hello Advanced User ...

Just wondering if you have a non-EXE solution (ZIP/RAR/7Z)? Alternatively, are they possibly INNO setups (which are easily extracted manually) or perhaps you inserted a: "/SWITCH" of some kind to manually extract?

I hate to run EXE setups when I know exactly where to put the files myself.

EDIT: ... dude, your English is great. Much much better than my Russian. Speaking of which, I cannot figure out how to download from those pages! Can you explain?

Not a problem because all files packed in cab installer and it can easily unpacked by WinRAR, but all usefulness of this packs just concluded in installing feature, so if you don't like to use setups then you don't need this packs.

There are two variants of downloading. With viewing the advertisment and without it. Look the instruction screens for both that cases: 1, 2.

RetroOS: From the link you provided about kernel32.dll,


NOTE: Per the previous sentence, I just copied it here, I wasn't involved in the testing. It was the person who posted
this comment.


On a similar issue for kernel32.dll errors being generated when I try to install googletoolbar v4.0.1602.1060 IE beta
on a Win 2k Pro SP4 system. I get this error which prevents it being installed.



And also this one.


Of course I'm trying to reinstall it which I can't due to these errors.



So, is my problem above due to Visual Studio 2008 not supporting Win 2K anymore? If so, then
the Google Toolbar people must being using VS 2008 although they say the toolbar can be installed
on a win 2K machine.

God ****. Show me who wrote that, i'll burn them with fire.

http://forums.msdn.microsoft.com/en-US/vcg...4-f1a40e8a3bb3/

Go to user 'mcb' dated Aug 25,2008. It currently is the last post here.

Let the flames start burning.

I think he meant with www.legacyextender.com software

I believe the traffic is now restricted to Russian-only domains.
Could you please use a non-restrictive host, such as uploaded.to, rapidshare.com or similar?

Dаmn, I have only now found out that Rapidshare has Collector's Zone service with downloads control ability. Then forget for instructions which i gave above, here are new rapidshare links: 2008 - 7.0 - 7.1 - 7.x

Thanks, found some interesting things there.
I had already patched and repacked beta2 of VC2008 for Win9x use, last year in November but didn't mess with the msi within, which still holds a system32 folder (should be system for Win9x).
Also I'm not familiar with the [BlockProductCode] section in the original install.ini.
I see you completely overhauled the installation process; I tried a minimal-change approach. Might give it another try when I feel like.

yes

Visual C++ 7.x Packs were updated. List of updated files include:

ATL71A.DLL 7.10.3077.0 -> 7.10.6088.0
ATL71U.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71CHS.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71CHT.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71DEU.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71ENU.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71ESP.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71FRA.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71ITA.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71JPN.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71KOR.DLL 7.10.6041.0 -> 7.10.6088.0
MFC71U.DLL 7.10.6041.0 -> 7.10.6088.0
MSVCI70.DLL 7.0.9466.0 -> 7.0.9955.0

All files were taken from original releases of Visual Studio .NET 2002-2003 and from official updates for it in Microsoft Download Center.

Tested on Windows 95-Vista but possible will work on Windows Seven too.

Look for updated links in previous posts (#23 and #30).

Visual C++ 7.x Packs were updated. List of updated files include:

ATL71A.DLL 7.10.6088.0 -> 7.10.6101.0
ATL71U.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71CHS.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71CHT.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71DEU.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71ENU.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71ESP.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71FRA.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71ITA.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71JPN.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71KOR.DLL 7.10.6088.0 -> 7.10.6101.0
MFC71U.DLL 7.10.6088.0 -> 7.10.6101.0

All files were taken from latest update for Visual Studio .NET 2003 in Microsoft Download Center.

Tested on Windows 95-Vista but possible will work on Windows Seven too.

Look for updated links in previous posts (#23 and #30).

few months ago i unpacked msvcr2008 with any extracting program (twice, or three times). later with Kernel EX 0.3.6 i executed the setup and copied the extracted files to system32 directory. After tests with some applications for visual studio 2008 i considered this manually installed package as fully working on windows 98 SE with newest KernelEX. i just had no time to make tutorial for this