enable visual style on mingw

[mattn]

related on #92

[NazmusLabs]

This enables visual styles on the about dialog box, correct?

[ZanderBrown]

In theory it does it everywhere for all compilers

Not sure how this will affect the 'retro' branch but Visual Styles was always going to be an issue there

[NazmusLabs]

@ZanderBrown That depends on whether we consider Windows XP support to be part of the retro branch or the master branch. If we keep retro branch for Windows 2000 or earlier, then there's no need to have anything related to the visual styles. If Windows XP, Server 2003 is part of the retro branch, well in that case, the MSDN article has a guide on how to have it fall back to version 5.

[mattn]

I checked this PR can built on Visual Studio too.

[ZanderBrown]

@NazmusLabs i think< 2000 is a good place to split it but if we wish to stay as close to master as possible we will need to do some degree of #ifdef, even more so is we do include XP

[craigwi]

I'm wondering if the split is at > WinXP (i.e., Win 2003 R2 and Vista).

That is, we have a branch for pre-VistaWin7 and one for Vista/Win7+.

[ZanderBrown]

So as far as I can tell this is the current proposal / state of play:

[NazmusLabs]

@ZanderBrown why is server 2003 not part of the retro branch if XP is? Sure, it's newer than XP, but it's very similar to how XP functions, no? Doesn't the split of pre Vista/7 and Vista/7+, as @craigwi noted, more logical?

[ZanderBrown]

Sure, hadn't noticed @craigwi had said 2003 R2 not 2003

[NazmusLabs]

@ZanderBrown Okay, but the point is the same, is it not? Server 2003 R2 is much, much, closer to Windows XP than is Windows Vista, no? As far as I know, the application platform's client APIs are identical to that of Windows XP whereas Windows Vista introduces new APIs on the client side. If I'm mistaken, do let me know.

P.S. I've finally recovered the archive of a genuine Server 2008 R2 VM I had and have successfully tested the visual styles compatibility in Windows 7 in high contrast. Result: it works, but there is a minor issue. If you switch from high contrast back to Aero theme, the toolbar icons become black boxes. An application restart fixes the issue. Another issue I noticed is that High DPI in Windows 7 and earlier does not work in this app when in High Contrast and classic themes. This is not a problem in Windows 10 and 8.x.

Notice that in the screenshots above, when in high contrast mode, the application is tiny.

[ZanderBrown]

This is why we need to need to have this discussion!

Seems a sensible place to draw the line

[craigwi]

My POV is the same as @ZanderBrown expressed just above (master supports >=2003 R2 and >= Vista).

I am amazed at the support for earlier versions of Windows and will create a ver9x branch to support that (as requested in other issues). I would like for the community to nominate one or two people to track / approve what's good for ver9x. Who should that be?

Same for mingw. Is that @mattn?

In case you don't know, I started at Microsoft before Windows 1.0!

[ZanderBrown]

I'm not sure mingw is worth being separate, it (& wine) only really require a Makefile and minor #ifdef

I'd like to nominate @MartinPayne and @NazmusLabs for retro

And you've been doing this for quite some time then @craigwi

[NazmusLabs]

@craigwi Windows 1.0? That's impressive, given how many changes and shifts happened in both the tech industry as well as the software development landscape throughout these years. Having to have worked through these different "eras", for the lack of a better word, must have given you perspectives most of us could only dream about.

So, might I ask, then? Did you ever partake in the development process of WinFile when it was shipped with Windows 3.x to NT4, either for a portion of its development or its entirety? If so, it's an honor to have someone who worked on the original code, regardless of scope, to be a part of the open source version.

[NazmusLabs]

To Support XP-64/Server 2003 In Master or Not To Support--That is the Question

As for the support for the OSes in the main branch, I would like to point out the following:

Build Numbers for XP vs Server 2003 R1 & R2

• Windows XP 32-bit (aka Version 2002): OS Build 5.1.2600
• Windows Server 2003 R1: OS Build 5.2.3790
• Windows Server 2003 R2: OS Build 5.2.3790
• Windows XP 64-bit (aka Version 2003): OS Build 5.2.3790

Main takeaway here is the following: Windows XP 64-bit (x64), Server 2003 R1, and Server 2003 R2 are built on th same underlying operating system, kernal, and platform APIs. Windows XP 32-bit is an outlier, sporting an older kernal and based on a two years older codebase.

This is very much the complete opposite of how things are today with Windows. Today, Server R1 and R2 releases are different builds of the operating systems, with R2 being made from a newer, upgraded codebase. And for client Windows today, the 32-bit and 64-bit versions are built form an identical codebase, meaning Windows 7 x86 and Windows 7 x64 are the same OS. In contrast Windows Server 2003 R1 and R2 are the same OS whereas Windows XP 64-bit is a newer and upgraded code to Windows XP 32-bit. These operating systems are, perhaps, a time capsule demonstrating how differently Windows division worked and did things back in the early 2000s, for better or for worse.

So, here's the breakdown: if the master branch decides to include support for Server 2003R2, by definition, it also supports Server 2003R1 and XP 64-bit, as the underlying operating systems, kernels, and platform APIs are identical. This means XP 32-bit is cut off from the master branch.

If, however, the master branch decides to support Vista and later, it would mean that the retro branch would have to support XP 32-bit, XP-64 bit, Server 2003 R1, and Server 2003 R2. It'd also mean that the retro branch would need a 64-bit binary for XP 64-bit and the 64-bit server versions.

So, the decision must be made either to put 64-bit XP and the Server 2003 R1&R2 releases as part of the master branch or with the retro branch, where Windows XP 32 bit and older falls.

My personal opinion is to have Server 2003 and XP-64 bit support as part of master, and XP-32 and older support be part of version 9.x.

[ZanderBrown]

... and suddenly we are back to my original diagram 😃

IIRC Vista is much closer to '03 than XP because of it's interesting development so there that to consider

As for XP x64 I completely forgot to include that! As XP x64 was somewhat odd is it worth supporting at all as such? If it is to be supported it does make sense for it to be on master even in '03 isn't.

Of course it's also important not to be too black & white on the divide, it maybe for 03/x64 that master&retro will 'support' them naturally so to speak

[ZanderBrown]

Okay so there was XP x64 & XP x64 Pro and it's the non-pro versions that were 'weird'

My understanding of @NazmusLabs's latest proposal, complete with some previously omitted windows releases

[NazmusLabs]

@ZanderBrown indeed, there was. I was kind of hoping you would not bring up the "weird" version of XP 64-bit. That version of XP is best left forgotten. And that version of XP is not x64 even though it's 64-but. Crazy I know, but bear with me for a sec.

First of all, the 64-bit xp I was referring to was XP x64, was only in Pro editon, and was based on the same OS as Server 2003. I wasn't even considering the "other" 64-bit XP. That is a version of xp "that shall not be named". It is a software example of a dark past in the history of Intel, and a portal to an alternate, much darker, reality. Something that could have been, but didn't, and thank God for that.

Windows XP Pro x64 is exactly what you expect. It's literally a 64 version of Windows. It's the predecessor of all x64 version of Windows we have today, including Windows 10 x64. It works like how you expect, supporting both 32-bit and 64-bit apps. It has a Program Files (x86) folder, as do other x64 Windows. It has perfect SysWOW64, making all existing 32-bit apps compatible. So, supporting XP x64 is automatic. Merely supporting Windows Server 2003 will automatically support XP x64. In fact, if anyone were to run XP in a virtual machine today, they would almost always want to install XP x64, as it's better than XP 32-bit in every way. The only reason to use 32-but XP is if you want to use it on an old 32-bit processor ancient hardware doesn't have 64-bit drivers.

Therefor, supporting XP Pro x64 is actually as important as supporting XP 32-bit, as anyone using XP in virtual machines will want to use the x64 version.

Now, that "other" XP. Right. That XP may not even launch the Winfile app, given you actually happen to find a still functionUS ancient PC capable of running that OS, one that was rare to get a hands on even in its heyday. No mainstream virtual machine software is, to my knowledge, capable of running Windows XP IA64. That OS was built for a reality that could have been, a reality we have thankfully, avoided.

Back in late 90s, we had left the 16-bit era. Windows 9x was the last OS that was a hybrid 32 bit and 16 bit OS, with Windows NT built as a pure 32-bit OS. By 2001, Windows XP was successful in porting all 9x features and DOS compatibility to the NT line. 32-bit was mainstream. Next stop: 64-bit. Intel had the "bright" idea to build a brand new 64-bit processor from the ground up. It was completely different from their current 32-bit architecture, which was based on thir 16-bit architecture which included the 286, 386, and 386, processors, hence the name x86. The new 64-bit Intel Processor was called Intel Itanium (IA64).

But there was a bad news. Since it was so different than the existing x86 processors, it meant the IA64 chips were dropping native support for all existing application. It was like moving from x86 to ARM64. Apps needed to be recompiled to IA64 to even run. You couldn't rely on just deploying an x86 app, expecting it to run perfectly, if at all. Windows XP IA64 did have a Wow layer, like how Windows 10 on ARM has, to emulate x86 apps. But apps would run slowly, would be buggy, and some wouldn't run at all. Had this actually happened, our computing industry would have been different. Compatibility with all retro software would be cut off. Winfile, or any other retro apps or games wouldn't just work with minimal changes in Windows 10 as they do today. That is, indeed, a dark reality. Macs may have continued using PowePC. The Xbox and PS4 consoles wouldn't be x86. But, thankfully, that is only a bad dream. Something that could have been, but hasn't happened. And the catalyst for that is AMD, which caused one of the biggest irony in the computer history.

AMD saw the stupidity of what Intel was trying to do. As it was struggling, it just realized that Intel was about to ditch the very platform that made them so powerful. AMD saw the golden opportunity. What if, rather than starting from scratch, they were able to figure out how to evolve the existing 32-bit x86 processor to 64-bit, as it was evolved from 16-bit. Sure, it's not as cutting edge as a brand new 21st century pure 64-bit processor. But the old x86 architecture was reliable, well understood, and most importantly, compatible. It could turn AMD around and allow it to be set for the next decade.

So they did. They created an evolved version of the x86 processor, that is essentially am extension of the 32-bit processor. They called it the x86-64 architecture, or x64, in short. We often refer to this as AMD-64. Now here's the biggest irony. Years ago, Intel licensed the x86 architecture to AMD to fend off potential legal issues in regards to abusing of monopoly powers. But now, Intel just realized they are screwed. They cannot compete against x64 with their Itanium. Intel's own architecture that it licensed to AMD has evolved to something that doomed IA64 before it even has a chance. So, Intel just waved the white flag and...wait for it, LICENSED x64 from AMD. So now, the two companies are licensing each other for the x86 processors we have today.

Microsoft, too, immediately saw the writing on the wall. x64 was nothing short of a miracle. All 32-bit existing apps "just worked". In fact, being an extension of an architecture from the 80s, 16-bit apps just worked. Even today, you can run MSDOS on an Intel 8th Gen Coffee Lake Processor. You can install 32-bit Windows 10 and run 16-bit apps on the the latest XEON processor. It was one of the biggest wins for backwards compatibility

Microsoft quickly built a x64 version of Windows xp. But by then Server 2003 was released. So XP x64 was built on OS build that powers Server 20003. XP IA64 was built on the original XP code (aka version 2002). But Microsoft being Microsoft, they don't just cut off support. So Microsoft did actuality bother releasing XP IA64 from the Server 2003 as well, just so that people who invested in the Itanium platform didn't get left out. But the rating was on the wall. Windows Vista never had an IA64 version, and while Windows server releases continued to offer IA64 versions, that too has eventually ended. Windows Server 2016, for instance, is only available in x64.

This is why you see the cryptic 64-bit xp that has a version 2002 and version 2003. This is why that version of XP not labeled as x64. It's a permanent reminder for the embarrassing turn Intel tried to take and how AMD turned the tables around the once dominant and unstoppable Intel. It's a reminder of how the computing industry could have been. It's an OS best left in the history books.

If I have made historical errors in this post, I offer my apologies and encourage corrections. And Allah (SWT) knows best.

[ZanderBrown]

Now @NazmusLabs has reminded us all of what we've tried to ignore with there epic post do we have some sense of agreement? @craigwi?

[craigwi]

Wow. Great write up @NazmusLabs! I always like to make data-driven decisions :)

Regarding an earlier question, no I didn't work on WinFile before I copied the sources in 2007. I was in the Office division from the beginning of my time at Microsoft in 1982 until late 1993 when I moved to Windows to ship 32bit COM/OLE in NT 3.51. Then I moved back to Office in late 1994, then to MSR in 1997, then back to Office in 2001 and then to Identity and Security in 2005 which is more or less where I am now (although on my fourth role -- my current role is what shows up on LinkedIn).

As for the primary question here, I agree with @NazmusLabs and @ZanderBrown on the retro / master cutoff (red 2003 line in the most recent diagram).

[craigwi]

We don't appear to need the "assemblyIdentity" section, do we? Such a section introduces another version number to keep up to date.

[craigwi]

These should be removed (my preference) or the x86 versions made to match.

[craigwi]

As to the PR, @mattn, I made a few comments on some details. I'm in favor of taking this since the result is the same as the #pragma and it helps the mingw version.

@ZanderBrown, would you mind adding the most recent version of your diagram to PR #88 since that is now referenced by readme.md?

[craigwi]

Also, I created the retro branch. @MartinPayne and @NazmusLabs, go for it. Perhaps PR #59 and perhaps others can be shifted to the retro branch. It may go without saying, but we should keep the retro branch focused on essential differences. I am open to changes to master that make that easier.

[mattn]

@craigwi Thanks for your review. Updated patch.

[craigwi]

Thanks. One last question. The change sets EmbedManifest to false for x64 (in vcxproj). Would it be better to not set that value or set it the same for all versions?

[mattn]

#ifdef __MINGW32__
CREATEPROCESS_MANIFEST_RESOURCE_ID RT_MANIFEST "winfile.exe.manifest"
#endif

If this part doesn't have ifdef, Visual Studio got an error (without EmbedManifest false). But now it is not required if it have __MINGW32__. So I removed EmbedManifest section.

[craigwi]

Thanks.