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

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

  • Weasel
    replied
    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.

    Leave a comment:


  • oiaohm
    replied
    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.

    Leave a comment:


  • Weasel
    replied
    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.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    In fact if you look at the header you linked to, you have #ifdef _USE_32BIT_TIME_T so in fact you have to explicitly ask for 32-bit time_t (which apps won't unless they have a reason to) for this library to even use it in the first place. Look at line 366.
    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. Last time I looked at that library 2 years ago it was still pure 32 bit time only.

    There is a reason why _USE_32BIT_TIME_T is still on in a lot of installer builds is the old msvcrt.dll does not have 64 bit time.

    And I'm still waiting for your proof that Adobe's CC installer screws up after 2038 and fails to install or whatever.
    My answer.
    Just shut the fuck up already stupid monkey. You don't know shit.
    Don't tell me to shut up then ask for something Weasel otherwise you will not get it. You have asked not to be given that answer so I am not giving it to you of course. Instead I am giving other data that proves the point.

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    https://github.com/Chuyu-Team/VC-LTL...10240.0/time.h

    Try again moron do some basic research before commenting. These hacks do contain a time.h files. Yes quoted something that different groups are using that end up using 32 bit time functions out of msvcrt.dll by time.h. There is more than 1 group that has implemented these wrappers. These wrappers are found used by different 32 bit installer source code.
    Are you fucking retarded? That's a time.h provided BY this library, and not msvcrt. Just because it is based on doesn't mean it just passes all calls through, in fact, if that were the case this library would be completely worthless. Clearly it must be doing something extra.

    In fact if you look at the header you linked to, you have #ifdef _USE_32BIT_TIME_T so in fact you have to explicitly ask for 32-bit time_t (which apps won't unless they have a reason to) for this library to even use it in the first place. Look at line 366.

    Just shut the fuck up already stupid monkey. You don't know shit.

    And I'm still waiting for your proof that Adobe's CC installer screws up after 2038 and fails to install or whatever.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    That project you linked to is a C++ runtime itself. So it probably provides its own time.h. What the fuck are you even on here?

    It's not a straight compilation to msvcrt because if it were so, then you wouldn't need that project in the first place, so it actually invalidates your point. It does link to msvcrt but who said it uses the time functions from there? Maybe it only uses printf or whatever. Seeing as it's a C++ runtime, it seems unlikely to even be using time.h since that's not even a C++ header.


    Try again moron do some basic research before commenting. These hacks do contain a time.h files. Yes quoted something that different groups are using that end up using 32 bit time functions out of msvcrt.dll by time.h. There is more than 1 group that has implemented these wrappers. These wrappers are found used by different 32 bit installer source code.

    VC-LTL is an open source CRT library based on the MS VCRT that reduce program binary size and say goodbye to Microsoft runtime DLLs, such as msvcr120.dll, api-ms-win-crt-time-l1-1-0.dll and other dependencies.
    Basic project description what doce CRT stand for. That right "C Run-time Library" so of course without question its going to contain time.h.

    The project I linked to was not a C++ runtime it was a C runtime that could be used with C++ programs. Basically you are wrong Weasel its about time you accept there are a stack of different 32 bit programs out there using c runtimes that are not 2038 compadible for windows and a lot of those are your 32 bit installers on 64 bit applications.

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    https://github.com/Chuyu-Team/VC-LTL/releases
    Beginning with VC-LTL 4.0, if you need static compilation (dependent msvcrt.dll only), please use
    Nothing says you will have build errors using time.h
    That project you linked to is a C++ runtime itself. So it probably provides its own time.h. What the fuck are you even on here?

    It's not a straight compilation to msvcrt because if it were so, then you wouldn't need that project in the first place, so it actually invalidates your point. It does link to msvcrt but who said it uses the time functions from there? Maybe it only uses printf or whatever. Seeing as it's a C++ runtime, it seems unlikely to even be using time.h since that's not even a C++ header.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    No it will have build errors if you use time.h (which you should not, use the Windows API instead).
    Shared to msvcrt.dll and optimize the C/C++ application file size. - Chuyu-Team/VC-LTL

    Beginning with VC-LTL 4.0, if you need static compilation (dependent msvcrt.dll only), please use
    Nothing says you will have build errors using time.h

    Originally posted by Weasel View Post
    Sure, that's why you use the Windows API itself in this case, and not time.h. Windows API is available everywhere, redistributable runtimes are not.
    You are not thinking how a lazy ass programmer making a installer works.

    1)Yes we lock to Windows API.
    2)Darn we want to display a picture using a static build library that is based on C that needs a runtime.
    3) Include something like VC-LTL that exploits msvcrt so giving you 32bit time_t so that the c runtime problem is solved and we have not added need for redistributable runtime.
    4) Build a 2038 incompatible installer today using msvcrt.dll.

    MIcrosoft tells you not to use msvcrt.dll but this does not stop programmers writing there own wrappers and using it anyhow from the latest version of MSVC as this is the fastest way they can get their installer built.

    As I said Microsoft needs to make using msvcrt.dll/crtdll.dll a error message.

    Yes a well behaved programmer making a installer will do what you said use the Windows API and in fact modify everything to work with only that if their is a issue. Problem is well behaved programmers making installers is not as common as the lazy ass programmers who just drop back to using msvcrt.dll or crtdll.dll. Adobe is not alone with this problem. Its a lot more common than you like. Thinking adobe programs only are legally install-able for a max of 3 years the fact they have 2038 issues don't matter to them.

    Leave a comment:


  • Weasel
    replied
    Originally posted by oiaohm View Post
    Horrible here is if you set MSVC to build without runtime you get msvcrt.dll instead of a versioned runtime for <time.h>
    No it will have build errors if you use time.h (which you should not, use the Windows API instead).

    Anyway still waiting for your proof that it uses msvcrt.dll, don't dodge the subject.

    Originally posted by oiaohm View Post
    You said you are a programmer cannot you not use basic common sense here and look at you are building a installer so it has to run with what will be on the target system without needing to add anything.
    Sure, that's why you use the Windows API itself in this case, and not time.h. Windows API is available everywhere, redistributable runtimes are not.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by Weasel View Post
    So you're saying the Adobe creative cloud setup is built with an old Visual Studio from 1995 that uses msvcrt.dll instead of versioned runtime?
    Horrible here is if you set MSVC to build without runtime you get msvcrt.dll instead of a versioned runtime for <time.h>

    Installers cannot magically install stuff before they run without having users have todo extra steps.

    Originally posted by Weasel View Post
    Uhm no all you have to do is compile with a different runtime (or change the compiler which does this by default).

    Or just use the Windows API directly like a sane app.
    Both of those options require you to rework you code base. Again it a installer so any option install-able run-time has to be off.

    The 32 bit installer nightmare with MSVC is what happens when you set it to build without using install-able runtime or build you installer with 32 bit mingw.

    You said you are a programmer cannot you not use basic common sense here and look at you are building a installer so it has to run with what will be on the target system without needing to add anything. Once you start setting MSVC up todo that you will notice time_t ends up locked as 32 bits on 32 bit builds even with newest version of the complier.

    Adobe is not alone with the problem. Yes Microsoft fixed it in the runtimes you install with your application for the application running after it installed. Microsoft has failed to fix the 32 bit time_t problem for when you are building 32 bit installers. I will give you that installer developers need to use Windows API directly for time operations more. Due to how bad this miss usage is using msvcrt/crtdll needs to come a error so people know about it and can request it fixed. Ok a clickable past error at this stage. You could check on the dynamic load.

    Leave a comment:

Working...
X