Announcement

Collapse
No announcement yet.

Wine Developers Appear Quite Apprehensive About Ubuntu's Plans To Drop 32-Bit Support

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

  • Originally posted by Weasel View Post
    Uh no, the Windows API operates with 64-bit time structs or with structs containing words for years/months/days/milliseconds, both of which won't overflow.


    Windows is the same as Linux here. In 32 bit mode you have both 64 bit time and 32 bit time. Microsoft uses different EPOCH for their 64 bit time on their file systems to Linux this is another thing that performance hit Linux binaries running in WSL1.

    You do find a lot of new programs using the _USE_32BIT_TIME_T as this means structures in data packets and the like have not changed sizes even that Microsoft warns you that you should not because this will break in 2038. The simplest way to be sure you not running anything effected by the 32 bit time_t problem under linux is only use 64 bit programs.

    Under windows you are cursed to hell Microsoft in their mega-wisdom decide to provide __time32_t__ in the 64 bit version of API and say to developers don't use that. Telling humans not to use something always fairly much makes sure someone uses it. Windows needs a 2038 check program.

    Comment


    • Originally posted by atomsymbol
      The 64-bit address space is practically infinite. The probability of there arising a need to extend the address space to 128-bits within our lifetimes is zero.
      You say that but... we're already starting to build hardware instructions sets for dealing with those size address spaces in specific user cases. Yes, a desktop wont need that memory space anytime soon, but its already in the silicon in production servers today.

      New Instruction Set Architecture Implemented on POWER9
      • 128-bit IEEE 754 Quad-Precision Float – Full width quad-precision for financial and security applications
      Source: https://indico.cern.ch/event/744165/...w_20180725.pdf

      Comment


      • Originally posted by the_scx View Post
        There is no more suitable way than multilib/multiarch. And never will be.
        I snipped away quite a bit of your reply, so let me answer in generic terms first and then I'll address this specific comment later.

        I'm a member of Ubuntu and Ubuntu is very important to me, but I've never wanted Ubuntu to be a special system. I obviously love that Valve recommends Ubuntu as an alternative to Windows and Mac, but the idea of Valve recommending Ubuntu becomes offensive to me once it's perceived as exclusive support among GNU+Linux distributions.

        Allow me to take a little trip in order to explain my point. My DNA test told me I'm 93% Norwegian and 7% Finnish, so I could probably drink a bottle of water that was labeled «For whites only», but that label would make me extremely suspicious of the water you're trying to sell me. If it's the kind of water I'm used to, then it's H2O and everyone should drink it. The question becomes whether or not you've added something to it in order to make it «whites only». In that case, I would have to ask what benefit that thing is to me and how you've determined that it's safe for whites when you've made it unsafe for non-whites. And then and only then, would I still not drink it, because it's extremely unethical, the thing you've done.

        Utilizing this cognitive framework, let's say I sell Ubuntu as bottled water that contains no allergens. It really doesn't mean anything, because as in the previous example, real water is real water. Other water distributors might be offended, feeling that we're implying that their water does contain allergens. But let's agree that no apology ever undoes the bad deed you've done. Microsoft has poisoned the waters and even when they ask for peace and we accept it, we still have to care about the fact that they have already poisoned the water. That is why I sell Ubuntu as safe water. I have to do that in order to attract my audience, which is the Microsoft Loyalist. I can't just tell them it'll feel good, because they think they'll die. I have to tell them using Ubuntu won't kill them. But then the PC community gets offended and they won't listen to my intentions but only my words. I have a four letter word for them.

        I've had so many people tell me they're now using Arch Linux, that were using Windows before I convinced them to try Ubuntu. That's what I do and that's my contribution to GNU+Linux. I love it. That's my goal. Teach them and set them free.

        Valve seems now to be selling the idea that their support for Ubuntu will have an impact. It won't, because Ubuntu was never special, never sought to be special and have never asked you to not support out social downstreams.

        «There is no more suitable way than multilib/multiarch. And never will be.»

        I've moved away from native desktop installs. I Use a stable Ubuntu Server LTS and then I just add virtual machines to that, which I can just toss around in my network as I see fit. I will never go back to native desktop installs again.

        You're pretty much describing Clarke's First Law.

        Comment


        • Originally posted by the_scx View Post
          Anyway, the Microsoft's position is quite clear on this:
          The Microsoft marketspeak is not what made me ring the death knell on UWP. Microsoft's actions speak louder than their words, and their actions are currently making UWP superfluous.

          How committed they are to a technology or product, and how committed they pretend they are is quite a different thing. This was the same for Zune, Kinect, Windows Phone/XNA/Silverlight, etc. which all were totally the greatest thing ever with the best future, until one day they suddenly weren't. And people who were able to read Microsoft's actions were not remotely as surprised as those who only read their PR statements.

          Also if Paul Thurrott doesn't know Microsoft, then I don't know who does.

          Originally posted by the_scx View Post
          Desktop Bridge in UWP
          Stop conflating UWP, the Store and Desktop Bridge. These have been decoupled from each other.
          Originally posted by the_scx View Post
          Again, there is no single native Win32 app in Mcrosoft Store. Each Win32 has to use Desktop Bridge. And it comes with limitations. It is almost the same situation as for Snaps.
          Microsoft will permit Store apps as native Win32 without Desktop Bridge: https://news.xbox.com/en-us/2019/05/...-to-pc-gaming/
          Originally posted by Phil Spencer, head of Microsoft Xbox
          We recognize that Win32 is the app format that game developers love to use and gamers love to play, so we are excited to share that we will be enabling full support for native Win32 games to the Microsoft Store on Windows.
          Yes, games only for now. But the crucial step towards native Win32 apps on the Store has been made.

          Originally posted by the_scx View Post


          Of course, I don't believe that they will succeed, but it doesn't matter here.
          What's the point here? The article only talks about problems, not about solutions. And the problem of running Chrome-based Edge on Win32-less Windows 10 Lite is unsolved as of now.

          Originally posted by the_scx View Post
          Both MonoDevelop and Visual Studio Code developers have dropped support for Flatpak (flatpak package for VSC is supported by community, but it is irrelevant here). Does it mean that Flatpak is dead?
          Where does MonoDevelop/VSC come from (hint: Microsoft), and where does Flatpak come from (hint: not Microsoft)? These are two very different organizations. If/when Ubuntu gives up on Snap as its primary sponsor, it will be dead. If/when Microsoft gives up on UWP, it will be dead. If/when Microsoft gives up on Flatpak, who cares?

          (That's not to say that the concept of Snap, Flatpak, etc. isn't horrible, and all of them shall die a flaming death. But that is a separate topic.)

          Originally posted by the_scx View Post
          Anyway, I never said that UWP will be successful. What matter here is how Microsoft see its future
          Yes.
          Originally posted by the_scx View Post
          and what is official statement.
          No.

          Originally posted by the_scx View Post
          Microsoft Store has been repeatedly described as the worst app store in history. But even so, it attracted more game developers than the Snap Store.
          That is because Microsoft Store is installed on like 1 billion devices, and Snap store is on 40+ million? With a completely different demographic? There is really no argument for you to make here.

          Originally posted by the_scx View Post
          It wouldn't be enough, because people expected support for the x86 Win32 applications. Microsoft tried to sell Windows RT as a new platform, like Android or Chrome OS are compared to the typical GNU/Linux distributions. But of course they failed.

          Oh, and now you see that lack of support x86 (including x86-32) is a problem. Great!
          Stop being deliberately obtuse, and stop putting words in my mouth. I did not claim that lack of x86 support is a problem, I used a conditional sentence ("If ... then").

          But yes, for Windows users the role that proprietary Win32 x86 applications play is far too great for a device that lacks those to be successful.
          For Linux users? Not so much, neither Win32 nor x86. The most successful desktop Linux distribution, Chrome OS, didn't support that without some major hackery in the past (developer mode + crouton). The situation is easing somewhat (crostini) but still no easy solution for Chrome OS users on ARM.

          Originally posted by the_scx View Post
          Microsoft already presented Windows 10 Continuum, but it doesn't worked out.
          I maintain that there wasn't anything remotely ready so far.
          • Microsoft Continuum was kinda ready for end users from the OS perspective, but the ecosystem wasn't ready (needs applications written in a special way, old WP8 apps won't support it, would have to drop WP8 support in order to enable Continuum support). Also Microsoft hardware did not support standard USB power delivery properly, and sometimes the Lumia 950/950XL would release the magic smoke when plugging into a standards-based USB-C charger... so it wasn't interoperable with something else than the official dock.
          • Ubuntu's smartphone OS could have gotten closer, but it failed to become ready for end users on the smartphone side. Which is kind of a deal breaker. Then Canonical pulled the plug.
          • Samsung DeX is too separate between the smartphone and desktop side, and the transition is hard: it does not allow smoothly continuing your work after docking/undocking.
          • Huawei's approach I don't know much about, but Huawei currently has other more serious problems.
          • Jolla appears to have also something in the works, but Jolla is too small to make a dent in the market and always on the edge of bankruptcy.
          Originally posted by the_scx View Post
          I never said that. All it needs is a f*cking multilib/multiarch support. It is the best and easiest way to provide support for i386 apps.
          But instead, we hear that we should use Snaps, LXD containers or even virtual machines. There is absolutely no reason to use QEMU-based virtualization and Virgl here, but some people here call it a "solution".

          Please, stop this bullsh*t. Multiarch support costs Canonical almost nothing. There is no other distro that have problem with this. Canonical has a lot of money from x86 desktop, and this is why they should support them properly.
          How much it costs is almost irrelevant. The question is the cost-benefit ratio. That is the entire point. Canonical has now a lot of negative PR at their hands, which probably they hadn't expected for their move. That probably affected their cost-benefit calculations, and caused them to backtrack.

          Originally posted by the_scx View Post
          It is clear to me that Canonical is not interested in serious support for Linux desktops, so it is not gonna happen. What is worse, support for ARM hardware (mainly Snapdragon-based ACPC laptops) is pathetic.
          On the contrary, Canonical depends on desktop marketshare in order to drive their cloud, server, etc. business. Same is true for ARM on servers, Linus Torvalds said it earlier this year: https://www.realworldtech.com/forum/...rpostid=183486

          Canonical knows that, and this is why they are now trying to focus on the areas where it actually matters. They dropped Mir and Ubuntu phone, because these were going nowhere, and development resources are best used elsewhere. They are phasing out i386 support, because that is irrelevant for most desktop users. There is two groups however (Wine and Steam users) that depend on i386 system libraries, and Canonical are now trying to find a way to get a smooth transition rather than quickly axing the whole thing.

          Originally posted by the_scx View Post
          Apart from numerous problems with various components, Freedreano is even worse than Nouveau, so there is no point to buy expensive hardware and use Linux on it, while support for Intel-based ultrabooks is almost flawless.
          Ubuntu is just packaging the stuff. I think the major work for Nouveau comes from Red Hat employees and the principal developer of Freedreno is formerly Red Hat and now at Google.

          Originally posted by the_scx View Post
          The point is that the Win32 and POSIX apps are "legacy", and UWP and PWA are "modern". But as we can see, modern not always mean better. The same applies to x86 vs RISC-V. That's all I wanted to say.
          Win32 isn't legacy, as much as Microsoft wishes this to be true, and tried to make it so. Win32 survived a lot of the technologies that came after it, and by the looks of it will also survive UWP. Microsoft is now bringing all formerly UWP-exclusive functionality to Win32, and that should be telling you something.

          Comment


          • Originally posted by chithanh View Post
            Weasel
            Citation? Just compile and run the following code yourself on 32-bit and 64-bit x86 Linux:
            Code:
            #include <stdio.h>
            #include <time.h>
            
            int main() {
            printf("The size of time_t is %zu\n", sizeof(time_t));
            }
            About your "bullshit" claim: Visual Studio up to version 2003 uses 32-bit time_t on x86. Since version 2005 it defaults to 64-bit time_t unless _USE_32BIT_TIME_T macro is defined[1, 2].
            So almost all Windows x86 software built with VS2003 or earlier and which uses time_t will potentially be affected by the year 2038 problem.
            Actually no because sane Windows apps use the Windows API instead of the crappy VS runtime.

            Comment


            • Originally posted by oiaohm View Post
              https://docs.microsoft.com/en-us/cpp...4?view=vs-2019

              Windows is the same as Linux here. In 32 bit mode you have both 64 bit time and 32 bit time. Microsoft uses different EPOCH for their 64 bit time on their file systems to Linux this is another thing that performance hit Linux binaries running in WSL1.
              That's not the Windows API, that's the VS redistributable runtime. Do you know why it is redistributable? Because it's not part of the OS. It's like supplying any other library. A library can even use 16-bit times if it wants to. Doesn't mean Windows API is at fault.

              Comment


              • Originally posted by Weasel View Post
                That's not the Windows API, that's the VS redistributable runtime. Do you know why it is redistributable? Because it's not part of the OS. It's like supplying any other library. A library can even use 16-bit times if it wants to. Doesn't mean Windows API is at fault.
                Not correct yes it in the VS redistributable and it in the crtdll.dll that is part of the Windows provided libraries and crtdll.dll not a redistributable fun part that one only has 32 bit time. When building with mingw you can choose to go against msvcrt.dll or crtdll.dll that both ship with windows as part of the provided ABI both have only 32 bit time.

                When using the newer redistributable you get 64 bit time but you have to install it to use it. Guess what ones 32 bit installers are using either msvcrt.dll or crtdll.dll because those are the ones they can be sure windows has. Yes these 32 bit installers of 64 bit programs are quite a big land mine.

                Comment


                • Originally posted by the_scx View Post
                  The problem is that they want to drop it. They literally want to remove multiarch support from Ubuntu 19.10+.
                  I did not understand that. What I understood was that they would stop shipping 32 bit packages. That's different from not offering multilib.

                  Comment


                  • Originally posted by oiaohm View Post
                    Not correct yes it in the VS redistributable and it in the crtdll.dll that is part of the Windows provided libraries and crtdll.dll not a redistributable fun part that one only has 32 bit time. When building with mingw you can choose to go against msvcrt.dll or crtdll.dll that both ship with windows as part of the provided ABI both have only 32 bit time.

                    When using the newer redistributable you get 64 bit time but you have to install it to use it. Guess what ones 32 bit installers are using either msvcrt.dll or crtdll.dll because those are the ones they can be sure windows has. Yes these 32 bit installers of 64 bit programs are quite a big land mine.
                    Ancient installers in Win95 era maybe, and it's still not the Windows API, it's only been promoted to system library because people abused it. (this was before versioned DLLs for each runtime). The thing is, even for those installers, nobody gives a crap about a wrong time. If they really fail to install due to bogus time, then set the clock to 1995 or whenever they were released, but I'm sure 99.99% of apps don't give a shit about the time (maybe time differences, but that doesn't matter).

                    Comment


                    • Originally posted by Weasel View Post
                      Ancient installers in Win95 era maybe, and it's still not the Windows API, it's only been promoted to system library because people abused it. (this was before versioned DLLs for each runtime). The thing is, even for those installers, nobody gives a crap about a wrong time. If they really fail to install due to bogus time, then set the clock to 1995 or whenever they were released, but I'm sure 99.99% of apps don't give a shit about the time (maybe time differences, but that doesn't matter).
                      Adobe creative cloud setup program anyone so its not Ancient Installers doing this. Its new 64 bit programs with 32 bit installer. Why the source code of their installers are ancient back to the Win95 era and while they still work they are not updating them. Microsoft could help by intentionally breaking both and displaying message past X date you have to be in compatibility mode to use old crtdll.dll and msvcrt.dll or all you will see when you attempt run program this program is no 2038 compatible please contact maker for instructions.

                      set the clock to 1995 you are not thinking how Microsoft worked around 2 digit dates are you. So a stunt like this is short term fix and you cannot write something like this into universal user instructions currently because 1995 might error out two digit date process because someone had excel/word open at the time. If you wish to change the clock to deal with the problem you really do need per application clock domains. So that problem applications run with the time they need and everything else on the system runs with the clock they are expecting.

                      Dealing with time issues is lot more complex than it first appears since we have multi different hacks dealing with different clock issues that have come up. Yes what you suggested could have triggered a Y2K fault on yourself just many years after Y2K. Defects in clock handling don't go way we only patch over them and if you are not careful how you patch over the next clock issue you trigger the prior ones all over again.

                      Per application clock domains will provide a good framework to deal with any future clock issue to appear once operating systems have it.

                      Comment

                      Working...
                      X