non-SSE2 binary for XP?

RainyShadowRainyShadow
in Requests

Since (AFAIK) MSVC 2017 comes with SSE2 optimisations enabled as default, overlooking it produces binaries incompatible with AthlonXP and similar processors.
I just upgraded to v.1.6.5 and got the following crash:

Code: c000001d (Illegal instruction)
Version: 1.6.5 (Dec 25 2018)
Major: 5
Minor: 1
Build: 2600
SP: 3
Type: 1
Time: 2020-08-14 22:22:38
TTH: 3A7JKMVDGYVRTGU7RO6C7HYEZIMIOWY2WX4O6VY

d:\development\dcdev\apexdc\trunk\openssl\crypto\asn1\ameth_lib.c(129): EVP_PKEY_asn1_find_str
d:\development\dcdev\apexdc\trunk\openssl\ssl\ssl_ciph.c(420): ssl_load_ciphers
d:\development\dcdev\apexdc\trunk\openssl\ssl\ssl_init.c(24): ossl_init_ssl_base_ossl_
d:\development\dcdev\apexdc\trunk\openssl\crypto\threads_win.c(85): CRYPTO_THREAD_run_once
d:\development\dcdev\apexdc\trunk\openssl\ssl\ssl_init.c(206): OPENSSL_init_ssl
d:\development\dcdev\apexdc\trunk\client\cryptomanager.cpp(54): dcpp::CryptoManager::CryptoManager
d:\development\dcdev\apexdc\trunk\client\dcplusplus.cpp(75): dcpp::startup
d:\development\dcdev\apexdc\trunk\windows\main.cpp(313): ::operator()
c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\include\future(704): std::_Packaged_state::_Call_immediate
c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\include\ppltasks.h(3537): Concurrency::task::_InitialTaskHandle<void=0x0028ABD8,=0x0028BFE8,Concurrency::details::_TypeSelectorNoAsync>::_Init
c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\include\ppltasks.h(16707566): Concurrency::details::_PPLTaskHandle::_InitialTaskHandle<void=0x0186FECC,=0x0070FA99,Concurrency::details::_TypeSelectorNoAsync>=0x00000000,Concurrency::details::_TaskProcHandle>::invoke
c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\include\pplwin.h(160): Concurrency::details::_TaskProcHandle::_RunChoreBridge
c:\program files (x86)\microsoft visual studio\2017\community\vc\tools\msvc\14.16.27023\include\pplwin.h(52): Concurrency::details::_DefaultPPLTaskScheduler::_PPLTaskChore::_Callback
d:\agent_work\2\s\src\vctools\crt\crtw32\stdcpp\thr\taskscheduler.cpp(166): Concurrency::details::`anonymous namespace'::_Task_scheduler_callback_xp
ntdll!0x7C92796D: RtlGUIDFromString
ntdll!0x7C9279AB: RtlGUIDFromString
ntdll!0x7C927A6D: RtlGUIDFromString
ntdll!0x7C927A44: RtlGUIDFromString
kernel32!0x7C80B729: GetModuleFileNameA

Would it be possible to update the ApexDC++_1.6.5_slim_XP.7z package with a SSE-only build, please?

Comments

  • CriseCrise
    edited September 2020

    Assuming I still have the means to compile XP binaries at all I could look into updating the binaries. Although IIRC I did disable some compiler options related to SSE2 already for XP builds.

    Hopefully you don't intend to run said binary on an actual XP machine, as such machine shouldn't be connected to an externally accessible network in the first place (in 2020).

    Edit: you have an interesting definition of just :D (the crash log you chose to include is is from Dec 2018).

  • RainyShadowRainyShadow

    @Crise said:
    Hopefully you don't intend to run said binary on an actual XP machine, as such machine shouldn't be connected to an externally accessible network in the first place (in 2020).

    Well, the XP machine is my main one :D (Un)fortunately, it is behind a NAT created by the router, which itself is behind the ISP NAT...

    @Crise said:
    Edit: you have an interesting definition of just :D (the crash log you chose to include is is from Dec 2018).

    I hadn't touched DC++ since a long time, then when i needed it my old ApexDC forced me to update to the latest available version 1.6.5 from Dec 2018. The log itself is from Aug 2020, as you can see in the 8th line.
    Which reminds me... Is there a way to override that behaviour and use the "expired" version (even if it's temporary)?

  • CriseCrise
    edited November 2020

    I know this is > @RainyShadow said:

    @Crise said:
    Hopefully you don't intend to run said binary on an actual XP machine, as such machine shouldn't be connected to an externally accessible network in the first place (in 2020).

    Well, the XP machine is my main one :D (Un)fortunately, it is behind a NAT created by the router, which itself is behind the ISP NAT...

    @Crise said:
    Edit: you have an interesting definition of just :D (the crash log you chose to include is is from Dec 2018).

    I hadn't touched DC++ since a long time, then when i needed it my old ApexDC forced me to update to the latest available version 1.6.5 from Dec 2018. The log itself is from Aug 2020, as you can see in the 8th line.
    Which reminds me... Is there a way to override that behaviour and use the "expired" version (even if it's temporary)?

    @RainyShadow Sorry for the late response, for what it is worth the current XP binary should already have only SSE instructions enabled, so no SSE2.

    Except for 64bit version of XP, for some reason, which you seem to be using :). So I'd suggest you try the 32bit binary for now.

    Also, apparently I really wasn't looking at the crash log closely enough, re the date mixup, in my defense it has been a while since I looked at one at all :D

  • RainyShadowRainyShadow

    @Crise
    I belive you're mistaken here. Since i get this crash, there must be a SSE2 instruction somewhere in the binary.
    The ApexDC++_1.6.5_slim_XP.7z file which is suggested for XP systems contains 4 files: ApexDC.exe, ApexDC.pdb, ApexDC-x64.exe, ApexDC-x64.pdb
    I had only ApexDC.exe and ApexDC.pdb extracted to my ApexDC++ folder, so i was definitely running the 32bit version. In fact, my XP won't even recognize the 64bit binary as executable.
    How did you conclude that i am running a 64bit version of XP? If it is because of the "c:\program files (x86)\" folder mentioned in the log, this should be a folder existing on the system that compiled the binary (your system), not mine. This is probably stored in the ApexDC.pdb file.
    Actually, if i could run 64bit XP here, we wouldn't be having this issue, because all 64bit processors support SSE2 :p

    Here is a new crash log - https://pastebin.com/ESi5vcU6
    And another one created after deleting the ApexDC.pdb file - https://pastebin.com/DyPCGqa9

    Let me ask again - can i use the expired version somehow without it forcing me to update to the crashing 1.6.5 version?

  • CriseCrise

    @RainyShadow My bad, you are absolutely correct re SSE2 support and x64

    I simply checked the compiler options and SSE2 should be disabled already for 32bit XP binaries. As to your last question, not really. Will send you a direct message with some more recent XP binaries to try :).

  • RainyShadowRainyShadow

    It still crashes with both test builds. I sent you a PM with the logs. Also accidentally posted an empty message on your profile page, sorry :P
    I tried clicking the "Continue" button about a dosen times, but it still goes back to the crash dialog.

    Do you embed some third party components in the .exe? Maybe one of those has SSE2 assembly inside? OpenSSL comes to mind...

  • RainyShadowRainyShadow

    Just tested in a VM in order to exclude the possibility of having some stray SSE2 shared library in my path... it still crashes.
    Attached logs for the original XP_slim binary and the two test builds.

Sign In or Register to comment.