Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSVC2 support #1

Open
malxau opened this issue Apr 27, 2018 · 1 comment
Open

MSVC2 support #1

malxau opened this issue Apr 27, 2018 · 1 comment

Comments

@malxau
Copy link

malxau commented Apr 27, 2018

I'm not sure what the goals are here, but I took what you had with MSVC 4.2 and moved it back to 2.0, and have a really hacky proof of concept functioning. It'd take a bit of work to clean up and integrate, so I wanted to check first what you're really after.

My thinking here is MSVC 2 is needed if the goal is to run on NT 3.1, because the 4.0 CRT doesn't really support 3.1. But going back to 3.1 isn't free, because it means the application subsystem is 3.x, which means it gets a 3.x UI:

wfclassic

As you've probably already seen, the toolbar pre 3.51 is totally different. Although they have a common ancestor they're different to the point that all window messages are different, so if the goal was to run across a range of versions it implies two implementations and picking one at runtime. Just to really make the point, MSVC 4's headers remove all trace of the pre-3.51 toolbar.

So...how classic is classic?

@MartinPayne
Copy link
Member

How much effort did it take, and how hacky is hacky? I did try compiling it in MSVC 2 but got a lot of errors. I didn't attempt to resolve the errors though, because my current focus is to get an ANSI build working in the hopes of getting this running on Windows 9x.

As for how classic classic is, that's still to be decided. I'm certainly not ruling out NT 3.1, but it's lower on the priority list than 9x. If we can get a build which works with both MSVC 2 and MSVC 4.2, I don't see an issue with the MSVC 2 build having a 3.1 appearance.

MartinPayne pushed a commit that referenced this issue May 6, 2018
NOTE: I'll fix the szParams buffer length issue when I fix the cmd.exe one.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants