Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by coder View Post
    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.

    Comment


    • #22
      Originally posted by tessio View Post

      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".

      Comment


      • #23
        Originally posted by tessio View Post
        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.

        Originally posted by tessio View Post
        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.

        Comment


        • #24
          Originally posted by coder View Post
          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.

          Comment


          • #25
            Originally posted by oiaohm View Post
            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.

            Originally posted by oiaohm View Post
            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.

            Comment


            • #26
              Originally posted by coder View Post
              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.

              Comment


              • #27
                Originally posted by skeevy420 View Post

                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.

                Comment


                • #28
                  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.

                  Comment


                  • #29
                    Originally posted by edwaleni View Post
                    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.

                    Comment


                    • #30
                      Originally posted by Weasel View Post
                      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.



                      Comment

                      Working...
                      X