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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • Weasel
    Senior Member
    • Feb 2017
    • 4497

    Originally posted by oiaohm View Post
    Ok so that one they finally updated to include a 64 bit time. But there are still many parts built on that using 32 bit time. As you said developed can still ask for _USE_32BIT_TIME_T and still get the broken.
    Developer can also use his own 16-bit time_t, what's your point? Developer can also shut down your system since installers have admin rights. Does it mean we have to remove the shutdown API to prevent abuse?

    Developer can do whatever he wants. Libraries are not magic nor privileged. They are the exact same as any other piece of user code since they get loaded into the address space of the process. In fact, this library you linked to is supposed to be statically linked. In other words, when your program is compiled to binary, there won't be a trace of this library, it will be part of the program's code itself.

    Comment

    • oiaohm
      Senior Member
      • Mar 2017
      • 8390

      Originally posted by Weasel View Post
      Developer can do whatever he wants. Libraries are not magic nor privileged. They are the exact same as any other piece of user code since they get loaded into the address space of the process. In fact, this library you linked to is supposed to be statically linked. In other words, when your program is compiled to binary, there won't be a trace of this library, it will be part of the program's code itself.
      Thing you missed is that 32 bit time usage is coming from the functions you see in the import table from msvcrt.dll. That static linked in library does not implement 32 bit time it using the implementation in msvcrt.dll. You have the balls to call me not a programmer. Its about time you look closer.

      I said when we started when developers are not using distributed run-times in their installers you find them using msvcrt.dll. I just showed you one of the ways it happens by a open source project there are many others. It does not change the fact that 32 bit installers on 64 bit binaries are using 32 bit time.

      Yes you cannot trace this to that the installer used VC-LTL exactly. But by the detectable usages of msvcrt.dll or crtdll.dll in the import table you can see that they have used something like VC-LTL and are using 32 bit time by in fact using msvcrt.dll or crtdll.dll functions 32 bit time functions instead of coding their own its the laziest way.

      Basically VC-LTL is one of many ways a installer maker can get a C runtime that does not need visual studio runtime installed. Of course most of these solutions have the horrible fact of using msvcrt.dll or crtdll.dll and defaulting to 32 bit time.

      Yes this is something microsoft could have moved to a compatibility database shim. As in remove the 32 bit time functions from msvcrt.dll/crtdll.dll and made the only way to access them use the shim after adding application to the compatibility database as well. Please note for over a decade now Microsoft documentation has said you are not meant to link against msvcrt.dll or crtdll.dll because they are for internal windows usage only.

      https://docs.microsoft.com/en-us/pre...4dbyh(v=vs.120)
      The msvcrt.dll is now a "known DLL," meaning that it is a system component owned and built by Windows. It is intended for future use only by system-level components.
      It really about time Microsoft starts enforcing this. You are new program you use msvcrt.dll or crtdll.dll you die. So that 32 bit time using installers start going away for good.

      Comment

      • Weasel
        Senior Member
        • Feb 2017
        • 4497

        Originally posted by oiaohm View Post
        Thing you missed is that 32 bit time usage is coming from the functions you see in the import table from msvcrt.dll. That static linked in library does not implement 32 bit time it using the implementation in msvcrt.dll. You have the balls to call me not a programmer. Its about time you look closer.
        Show the code where it is using it if you aren't explicitly asking for it.

        I see it is using inline functions that call _ctime64 and _difftime64. While I don't know what the function does, 64 in its name is kinda self-explanatory here, dummy.

        So yeah, you're definitely not a programmer, can't even read the code that you linked.

        Originally posted by oiaohm View Post
        Yes you cannot trace this to that the installer used VC-LTL exactly. But by the detectable usages of msvcrt.dll or crtdll.dll in the import table you can see that they have used something like VC-LTL and are using 32 bit time by in fact using msvcrt.dll or crtdll.dll functions 32 bit time functions instead of coding their own its the laziest way.
        Actually no, all you will see is that they are using _ctime64 or _difftime64 or the like. It's in the fucking code you linked.

        Again, unless you explicitly ask for 32-bit time functions, in this case, you can do whatever you want. Even 16-bit times if that's your thing.

        I know it's a shock to you that you can add new functions and exports to an existing library. msvcrt didn't change its 32-bit time functions, it just added 64-bit ones, and libraries like the one you linked transparently map to those with inline functions. Both functions exist at the same time, and all is good, ABI is preserved.

        It's a shock to morons like you since it's a thing that seems impossible in Linux userland; instead of adding new APIs, just replaces the original ones, breaking the ABI, because fashionistas must delete "old cruft". That's why it's pathetic.

        The kernel also does the same thing: it adds new syscalls, and keeps the old. Forever. Which is why the Linux kernel has a stable ABI.
        Last edited by Weasel; 02 July 2019, 12:06 PM.

        Comment

        Working...
        X