Announcement
Collapse
No announcement yet.
Wine & Mingw-w64 Might Tighten Up Their Relationship - Possible "WineSDK"
Collapse
X
-
Originally posted by coder View PostSo what? That changes nothing.
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.
- Likes 1
Comment
-
Originally posted by oiaohm View PostWine 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.
Originally posted by oiaohm View PostIf that is what happens would really is the WineSDK.
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.
Comment
-
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.
Comment
-
Originally posted by RealNC View PostMingw is for building Windows applications, not for developing Linux or Mac applications that run in Wine.
If it wasn't a Proton build requirement, I wouldn't have it installed.
- Likes 1
Comment
-
Originally posted by coder View PostIf 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.
- Likes 1
Comment
-
Originally posted by oiaohm View PostIf 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 can be developing an app for Windows 95 and that's not Wine so your point is invalid because it's still Windows.
- Likes 1
Comment
-
Originally posted by Weasel View PostYou 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.
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.
- Likes 1
Comment
-
-
Comment