Wine & Mingw-w64 Might Tighten Up Their Relationship - Possible "WineSDK"

[tessio]

Of course you can, just like you can also run fdisk in a VM. Just because fdisk also works on virtual disks the same way as physical ones isn't a reason to rename it fvdisk.

What? No one is changing Mingw-w64's name to convey a meaning about where it can run. They are changing because It will be developed under the bigger Wine project umbrella. And, let's face it, because Mingw-64 is a horrible name.

[skeevy420]

And, let's face it, because Mingw-64 is a horrible name.

It really is a horrible name.

Also, when I see it spelled like MinGW-64 I, for some reason, read it as "Min George Dubya 64".

[coder]

They are changing because It will be developed under the bigger Wine project umbrella.

Just because it makes sense from one perspective doesn't mean it won't cause confusion from others. Normally, names like "XYZ SDK" imply a SDK for the XYZ platform - as in, to develop code to run on XYZ.

And, let's face it, because Mingw-64 is a horrible name.

It's like jumping out of the frying pan and into the fire.

If the goal of the "rebranding" exercise is to get more people using it, then you want a name that won't make people think it doesn't apply to their use case. Calling it WineSDK or Wine-anything makes it sound like it's only used with/for Wine. It's the person who doesn't know anything about it that you should care the most about. They're the ones who need to be attracted by the name, rather than put off.

[oiaohm]

If the goal of the "rebranding" exercise is to get more people using it, then you want a name that won't make people think it doesn't apply to their use case. Calling it WineSDK or Wine-anything makes it sound like it's only used with/for Wine. It's the person who doesn't know anything about it that you should care the most about. They're the ones who need to be attracted by the name, rather than put off.

We have a problem here that Wine is not just the big that runs under Linux. Wine does have PE builds where as much as possible is built as PE file that can be used under Windows/Reactos.

Windows SDK built stuff can be used on Wine with limitations at times. People should get use to accepting the reverse that Wine stuff can be used on windows.

Wine old project Wine Is Not an Emulator. People in recent years have forgot this. Wine is a compatibility layer. Even the first version of wine had options to built parts of wine for windows.

Basically there has been a long term problem in way Wine project has been presented. Sometimes you just need to bite the bullet and fix it so the long term is better.

[coder]

We have a problem here that Wine is not just the big that runs under Linux. Wine does have PE builds where as much as possible is built as PE file that can be used under Windows/Reactos.

Even if you say this, probably 99.9% of actual WINE usage is to run Windows programs on non-Windows platforms.

Basically there has been a long term problem in way Wine project has been presented.

Taking this as given, then your branding problem is with WINE. You don't fix that by applying the WINE label to other things, nor is it best remedied by repeating a slogan that it's not an emulator. The rebranding really should focus on WINE, itself, and how it's packaged and distributed to support the various different usage models you describe.

[oiaohm]

Even if you say this, probably 99.9% of actual WINE usage is to run Windows programs on non-Windows platforms

This is not in fact true. Its out by a massive number. WineD3D for Windows used by people running old games on Windows has more users than Wine running Windows programs on non-Windows Platforms.

Basically you just said the myth not the facts of the matter. How Wine is really used is lost with the current Wine marketing. Codeweavers don't see that Windows users would be willing to pay to run old applications.

The brand and marketing of Wine absolutely does not match the market share of it users in current form.

[RealNC]

My only use of Mingw is compiling Proton...to build a Linux application that other people develop that runs in Wine... My one and only use case is exactly what you say Ming isn't supposed to be for.

If it wasn't a Proton build requirement, I wouldn't have it installed.

With that logic, GCC should be renamed to LinuxSDK, because it's needed to build the Linux kernel.

[edwaleni]

Wine is great but don't people realize that if it gets "too good" or better yet "too easy", all it will take is MSFT to require a certificate issued only by them for Windows apps to run and the future of Wine stops.

I think its great the work that has been accomplished and is yet to come, but that it's path to improvement simply brings it closer to its demise?

MSFT will do it in the name of security.

[Weasel]

Wine is great but don't people realize that if it gets "too good" or better yet "too easy", all it will take is MSFT to require a certificate issued only by them for Windows apps to run and the future of Wine stops.

Bad example. Wine can just ignore the certificate and run the app anyway.

[edwaleni]

Bad example. Wine can just ignore the certificate and run the app anyway.

It can be anything.....cert, exe change, dll changes. Something that would be unique enough under a security banner that would make Wine obsolete.

Since they willingly leave prior Windows versions behind, I can see them do the same with legacy apps as well.