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

[coder]

Parts of wine are used for running old windows programs on newer versions of Windows and also used inside different virtual machine solutions with windows.

Thanks for the info.

Mingw with wine header files is used for building wine testsuite to run on windows for compare testing.

So what? That changes nothing.

[oiaohm]

So what? That changes nothing.

Wine has not being using mingw-runtime header files or .a files when building its testsuite. So mingw wine cooperation could be "Headers, Libraries and Runtime" end up replaced with the wine ones. If that is what happens would really is the WineSDK.

Its like how you have cygwin and mingw. The gcc complier at the core of those is the same the different is the runtime.

Basically how wine project is currently using the mingw projects is fairly much gut it. If the result is basically the runtime setup used to make the test suite in wine cut out and put with mingw/cygwin gcc and binutils the correct name would be WineSDK if you were after the name that matched the majority of the source code making it up.

Of course if a different name gets selected as well that is fine. Its not like the WineSDK name is cannot be justified by logic based off the history naming of cygwin and mingw. So WineSDK would not be an out there name.

[coder]

Wine has not being using mingw-runtime header files or .a files when building its testsuite. So mingw wine cooperation could be "Headers, Libraries and Runtime" end up replaced with the wine ones.

That's a special case. There are also special cases where gcc is used on other platforms without any of its normal runtime libraries, but those cases don't define the toolchain. Those are the exception - not the rule!

If that is what happens would really is the WineSDK.

If someone is already decided to name it WineSDK and just looking for the thinnest of technicalities by which to justify such "branding", perhaps you can make it stick. But, if you actually want its name to reflect how most people use it, then you should accept that it's not principally used to develop software to run on Wine, and therefore wouldn't qualify as a Wine SDK.

A good name conveys the purpose or use of a thing. An average name is simply an opaque and largely unambiguous handle by which to refer to the thing. A bad name is actually misleading and likely to cause confusion. I think MinGW falls pretty much in the middle category, while WineSDK falls squarely in the latter category. It's fine, if you disagree.

[coder]

BTW, if what we're really talking about is a special package that bundles Wine's libraries with MinGW, for use with Wine - and not the standard release tarball of MinGW - then it's of course reasonable to call such a package a WineSDK.

Again, the point of a good name is to convey its use. So, if something is indeed designed specifically for developing software to run on Wine, then it's fine to call that a Wine SDK.

[skeevy420]

Mingw is for building Windows applications, not for developing Linux or Mac applications that run in Wine.

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.

[oiaohm]

If someone is already decided to name it WineSDK and just looking for the thinnest of technicalities by which to justify such "branding", perhaps you can make it stick. But, if you actually want its name to reflect how most people use it, then you should accept that it's not principally used to develop software to run on Wine, and therefore wouldn't qualify as a Wine SDK.

If the headers and library interfaces are directly based off wine ones it would make applications more likely to work under Wine than Windows. Wine has functions that are no more under Windows. Naming WineSDK would kind of give clear warning about that problem too.

[Weasel]

If the headers and library interfaces are directly based off wine ones it would make applications more likely to work under Wine than Windows. Wine has functions that are no more under Windows. Naming WineSDK would kind of give clear warning about that problem too.

You must have missing grey matter up there.

You can be developing an app for Windows 95 and that's not Wine so your point is invalid because it's still Windows.

[oiaohm]

You must have missing grey matter up there.

You can be developing an app for Windows 95 and that's not Wine so your point is invalid because it's still Windows.

Who says you cannot be using a Windows 95 API function that was removed in windows 2000 along side a Windows 10 added API. Yes using wine header and spec files it possible to make such a abomination.

Wine is basically its own version of Windows. Wine API/ABI is a combination of multi versions of Windows its really simple to forget this.

Basically you are the one missing grey matter here Weasel you have not considered why I said more likely to work under Wine than Windows. There is something really radically different about Wine API/ABI to Windows release API/ABI.

[tessio]

Mingw is for building Windows applications, not for developing Linux or Mac applications that run in Wine.

So?
Wine is just a re-implementation of windows libraries. No where it says you can only use it on Linux or Mac.

[coder]

No where it says you can only use it on Linux or Mac.

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.