FranceBB

I just changed the values in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Language Default: 0409 InstallLanguage: 0409 I'm now downloading the Service Pack 4 (instead of SP3), so hopefully I won't have to reinstall too many updates. Hopefully it's gonna work. I'll let you know.

@Mathwiz it's a localised version of Windows Professional. MUI it's just not there: Can I "convert" a localised version of XP into a MUI one? I googled the "Language Interface Pack" and I found a link https://www.microsoft.com/en-gb/download/details.aspx?id=1231 but it just lets me download "Readme.html" (3kb).

@VistaLover I mean the C python one by PolarNick for MinGW using MSYS2. It just works around kernel calls that are not implemented in XP like so: --- a/PC/python.manifest +++ b/PC/python.manifest @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> - <trustInfo> + <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="asInvoker" uiAccess="false"/> --- a/Modules/posixmodule.c +++ b/Modules/posixmodule.c @@ -1445,6 +1445,31 @@ return TRUE; } +/* Grab GetFinalPathNameByHandle dynamically from kernel32 */ +static int has_GetFinalPathNameByHandle = -1; +static DWORD (CALLBACK *Py_GetFinalPathNameByHandleW)(HANDLE, LPWSTR, DWORD, + DWORD); +static int +check_GetFinalPathNameByHandle() +{ + HINSTANCE hKernel32; + DWORD (CALLBACK *Py_GetFinalPathNameByHandleA)(HANDLE, LPSTR, DWORD, + DWORD); + + /* only recheck */ + if (-1 == has_GetFinalPathNameByHandle) + { + hKernel32 = GetModuleHandleW(L"KERNEL32"); + *(FARPROC*)&Py_GetFinalPathNameByHandleA = GetProcAddress(hKernel32, + "GetFinalPathNameByHandleA"); + *(FARPROC*)&Py_GetFinalPathNameByHandleW = GetProcAddress(hKernel32, + "GetFinalPathNameByHandleW"); + has_GetFinalPathNameByHandle = Py_GetFinalPathNameByHandleA && + Py_GetFinalPathNameByHandleW; + } + return has_GetFinalPathNameByHandle; +} + static BOOL get_target_path(HANDLE hdl, wchar_t **target_path) { @@ -1453,7 +1479,7 @@ /* We have a good handle to the target, use it to determine the target path name (then we'll call lstat on it). */ - buf_size = GetFinalPathNameByHandleW(hdl, 0, 0, + buf_size = Py_GetFinalPathNameByHandleW(hdl, 0, 0, VOLUME_NAME_DOS); if(!buf_size) return FALSE; @@ -1464,7 +1490,7 @@ return FALSE; } - result_length = GetFinalPathNameByHandleW(hdl, + result_length = Py_GetFinalPathNameByHandleW(hdl, buf, buf_size, VOLUME_NAME_DOS); if(!result_length) { @@ -1497,6 +1523,12 @@ wchar_t *target_path; const char *dot; + if(!check_GetFinalPathNameByHandle()) { + /* If the OS doesn't have GetFinalPathNameByHandle, don't + traverse reparse point. */ + traverse = FALSE; + } + hFile = CreateFileA( path, FILE_READ_ATTRIBUTES, /* desired access */ @@ -1587,6 +1619,12 @@ wchar_t *target_path; const wchar_t *dot; + if(!check_GetFinalPathNameByHandle()) { + /* If the OS doesn't have GetFinalPathNameByHandle, don't + traverse reparse point. */ + traverse = FALSE; + } + hFile = CreateFileW( path, FILE_READ_ATTRIBUTES, /* desired access */ @@ -3824,6 +3862,13 @@ if (path_wchar == NULL) return NULL; + if(!check_GetFinalPathNameByHandle()) { + /* If the OS doesn't have GetFinalPathNameByHandle, return a + NotImplementedError. */ + return PyErr_Format(PyExc_NotImplementedError, + "GetFinalPathNameByHandle not available on this platform"); + } + hFile = CreateFileW( path_wchar, 0, /* desired access */ @@ -3839,7 +3884,7 @@ /* We have a good handle to the target, use it to determine the target path name. */ - buf_size = GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT); + buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT); if(!buf_size) return win32_error_object("GetFinalPathNameByHandle", path); @@ -3848,7 +3893,7 @@ if(!target_path) return PyErr_NoMemory(); - result_length = GetFinalPathNameByHandleW(hFile, target_path, + result_length = Py_GetFinalPathNameByHandleW(hFile, target_path, buf_size, VOLUME_NAME_DOS); if(!result_length) return win32_error_object("GetFinalPathNamyByHandle", path); --- a/Python/pytime.c +++ b/Python/pytime.c @@ -463,7 +463,7 @@ /* 11,644,473,600,000,000,000: number of nanoseconds between the 1st january 1601 and the 1st january 1970 (369 years + 89 leap days). */ - *tp = large.QuadPart * 100 - 11644473600000000000; + *tp = large.QuadPart * 100 - 11644473600000000000ULL; if (info) { DWORD timeAdjustment, timeIncrement; BOOL isTimeAdjustmentDisabled, ok; @@ -557,6 +557,32 @@ return pygettimeofday(t, info, 1); } +/* GetTickCount64() is not available on XP. */ +ULONGLONG GetTickCount64_Alternative () +{ + static ULONGLONG (CALLBACK *Py_GetTickCount64)() = (ULONGLONG (CALLBACK *)(void))-1; + static DWORD last_ticks = 0; + static DWORD n_overflow = 0; + DWORD ticks = 0; + HINSTANCE hKernel32; + + if (Py_GetTickCount64 == (void*)-1) + { + hKernel32 = GetModuleHandleW(L"KERNEL32"); + Py_GetTickCount64 = *(ULONGLONG (CALLBACK *)(void))(GetProcAddress(hKernel32, + "GetTickCount64")); + } + if (Py_GetTickCount64 != (void*) NULL) + { + return Py_GetTickCount64(); + } + + ticks = GetTickCount(); + if (ticks < last_ticks) + n_overflow++; + last_ticks = ticks; + return ((ULONGLONG)n_overflow << 32LL) + (ULONGLONG)GetTickCount(); +} static int pymonotonic(_PyTime_t *tp, _Py_clock_info_t *info, int raise) @@ -566,7 +592,7 @@ assert(info == NULL || raise); - result = GetTickCount64(); + result = GetTickCount64_Alternative(); https://gist.github.com/PolarNick239/5168c2bbf2731171bc190a465cc4d052 By the way, it seems that the author of xompie has been working on a newer version of python (3.5.2): https://opensourcepack.blogspot.com/2016/10/python-352-on-xp.html?m=1

I installed my XP copy many years ago, in 2002. Since then, I managed to move it from Hard Drive to Hard Drive, motherboard to motherboard, CPU to CPU and so on by just using a clone-disk utility. Anyway, I moved to the UK in 2015 and I'd like to have my OS in English, 'cause it kinda feels weird and annoying to have it in Italian. I mean, I already have everything in English (my mobile is in English, my TV is in English, my washing machine is in English, my microwave oven is in English, my Linux installation is in English, my Windows Server 2019 installation is in English) so why can't my XP be in English? I've found somewhere on internet that I can modify a registry value and install the Service Pack 3, however I have an updated XP with all the POSReady updates; re-installing SP3 would overwrite the updated system files (and I don't want that). Then, I came across the EgyMore Language Pack for Windows XP, but guess what? It doesn't have English! I don't wanna make a fresh-new install of my Windows XP, so I ask you: what other options do I have? Thank you in advance, Frank.

@Mathwiz I see... Perhaps I forgot to include something back then. It just baffled me that nobody noticed it for years... @someguy25 I'm not really sure about what I did in 2015/2016, but I tried make a new installer and it found 3481 dependencies and I have now included them all. New Installer (of the old 3.5 project): Link EXE header size: 50688 / 37888 bytes Install code: 30540 / 202408 bytes Install data: 24995897 / 116377752 bytes CRC (0xE68CCFD0): 4 / 4 bytes

Exactly. And I'm pretty sure they'll start doing the same thing for Windows 7 soon...

Actually, it was working on my computer in 2015 and it still is now. It must be something about your configuration. Anyway, years passed and nowadays Python 3.7.1 is out. Programmes written using 3.7.1 capabilities won't be able to be compiled at runtime by Python 3.5 anyway, so even if you manage to get it up and running, it would be useless for programmes written after 2016. Someone should backport a newer version of Python. @someguy25 I noticed that you opened a topic already about newer version of Python, but as @Dibya said, there's no guarantee that it will be working. It's a magical place... to a certain extent. xD

Actually, there's no need for the site 'cause Samuel made the project open source (you can find the source code here: https://github.com/Skulltrail192/One-Core-Api?files=1

Oh, nope, sorry, my bad, I was thinking about Windows Embedded for Point of Service which ended on April 12, 2016. POSReady 2009 ends on April 9.

Download MSYS2: http://repo.msys2.org/distrib/x86_64/msys2-x86_64-20180531.exe Download and run the installer - "x86_64". Click "Next". Enter Installation Folder "C:\msys64". Tick Run MSYS2 now Update the package database and core system packages by typing the following command the MSYS2 console: pacman -Syu Update the make package: pacman -S make Install GCC: pacman -S gcc Remove link.exe in the MSYS2 usr bin folder (C:\msys64\usr\bin\link.exe) Install perl: pacman -S perl Install diffutils: pacman -S diffutils Download YASM: http://www.tortall.net/projects/yasm/releases/yasm-1.3.0-win64.exe Rename the downloaded executable to yasm.exe and place it in your MSYS2 path: "C:\msys64\usr\bin\yasm.exe". Download gas-preprocessor: https://github.com/FFmpeg/gas-preprocessor/blob/master/gas-preprocessor.pl Place the downloaded Perl script in your MSYS2 path: "C:\msys64\usr\bin\gas-preprocessor.pl". Launch VS2015 x86 x64 Cross Tools Command Prompt: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2015\Visual Studio Tools\Windows Desktop Command Prompts\VS2015 x86 x64 Cross Tools Command Prompt Set the following environment variables in the launched command prompt above: SET LIB=%VSINSTALLDIR%VC\lib\store\amd64;%VSINSTALLDIR%VC\atlmfc\lib\amd64;%UniversalCRTSdkDir%lib\%UCRTVersion%\ucrt\x64;;%UniversalCRTSdkDir%lib\%UCRTVersion%\um\x64;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\lib\um\x64;;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\Lib\um\x64 SET LIBPATH=%VSINSTALLDIR%VC\atlmfc\lib\amd64;%VSINSTALLDIR%VC\lib\amd64; SET INCLUDE=%VSINSTALLDIR%VC\include;%VSINSTALLDIR%VC\atlmfc\include;%UniversalCRTSdkDir%Include\%UCRTVersion%\ucrt;%UniversalCRTSdkDir%Include\%UCRTVersion%\um;%UniversalCRTSdkDir%Include\%UCRTVersion%\shared;%UniversalCRTSdkDir%Include\%UCRTVersion%\winrt;C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6\Include\um; Open MSYS2 Shell from the command prompt above: C:\msys64\msys2_shell.cmd Download FFmpeg from GitHub (click "Clone/Download"): https://github.com/FFmpeg/FFmpeg Place the folder in C. In your MSYS2 shell navigate to your cloned FFmpeg folder: Invoke the following make commands: mkdir -p Output/Windows/x64 Then navigate to the newly created folder: cd Output/Windows/x64 Type the following commands: ../../../configure \ --toolchain=msvc \ --disable-programs \ --disable-d3d11va \ --disable-dxva2 \ --arch=x86_64 \ --enable-shared \ --enable-cross-compile \ --target-os=win32 \ --extra-cflags="-MD -DWINAPI_FAMILY=WINAPI_FAMILY_APP -D_WIN32_WINNT=0x0A00" \ --extra-ldflags="-APPCONTAINER WindowsApp.lib" \ --prefix=../../../Build/Windows/x64 make make install It will take quite some time to compile. Once everything is done, you'll find the binaries in "Build/Windows/x64". Please note that these binaries WILL NOT work on Windows XP/Vista x64. In order to make them work, you gotta disable more things, not just d3d11 and dxva2. For instance, VistaLover said that libmfx breaks XP as well, but I don't know what else. Besides, compiling ffmpeg to make it work on XP/Vista has become trickier with time. Last time I did it was a year ago; I have used Corone's build ever since. Your best shot is asking @CoRoNe what must be disabled. Cheers and regards.

Definitely Windows Embedded Standard, which is still supported 'till January 8th 2019 or POSReady which is supported 'till April 12 2019. By the way, WES and POSReady are spread all over the world not just in ATMs, but also in fuel pumps, train stations, tills, self-checkouts, and so on.

Ask Corone directly, he's the one that is supporting ffmpeg on WinXP. By the way, all you need is Visual Studio 2017, GCC and Perl via MSYS2 and YASM. Actually, it works fine on Windows Server 2019. I think you could try to use Visual Studio 2012 and MSYS, but please note that the code is not C89 complaint, so you would have to modify it. Anyway, which platform are you targeting? Unless you are targeting XP/Vista, every other platform is pretty straightforward. Just follow the guide on the official site

Ok, so this time there aren't missing dependencies, it just fails to load, which is weird 'cause it means that it's something related to your system. Honestly, I don't know why it doesn't work on your system, as I tried it on a few other systems and it was working fine, especially 'cause I included every dependency needed. Besides, the message you are getting is related to the C++ Redistributable. Do you have an updated system? Which Antivirus do you have? Can you check that whatever antivirus you are using it's not interfering with the executable? (Please note that it's not digitally signed, so some antivirus products might not like it). https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads @Dibyacan you try to run it on your XP as well? It's just to make sure that the issue is related to his system. After all, the installer works for someguy25 as well as in my virtual machine.

@sdfox7 hopefully, this time it will work for you as well: Link

Crap... it happens on my system too. It's the UI rendering engine that misbehaves on XP 'cause buttons are supposed to be slightly rounded, but they are rendered as square on XP, therefore you get black at the edges. This is how they are supposed to look like (Windows Server 2019):

@Dave-H... that's unfortunate. I'm running Avast Premier Beta 18.7.2354 (build 18.7.4041.389) and I don't have any issues. There have been issues with some XP systems in the past, but I thought they were all sorted out. (By the way, I gave discounts to all my friends 'till few months ago as I was still able to. I would have given you a big fat discount if I knew you wanted to buy it).

We've been discussing about this here on MSFN (I don't remember in which topic, though). Anyway, the reason is that every year Avast releases a new version of its Antivirus with a new UI and new tools, however Avast 18 is already a pretty solid product which offers many tools included within the program and it's very reliable. Some of the tools already available in Avast 18 are a Firewall, a WiFi Inspector to find vulnerabilities, RealSite to make sure your DNS are legit, a Sandbox to run programmes in a protected environment, Passwords to safely store all your passwords (it works with Firefox ESR 52.9, it doesn't work with Chrome 49 nor Chromium 54), a Sensitive Data Shield to encrypt your personal informations, a WebCam Shield to prevent unauthorized access to your webcam, Data Shredder to overwrite with the zero-fill method an hard drive and make deleted files impossible to recover, Boot-Scan to use a CHKDSK-Like method to run Avast when Windows is not running (to get rid of the nastier threats), an automatic software and driver update mechanism that checks for newer versions of the programmes/drivers you have installed and can install them in background or just notify you, Recovery Disk Tool with which you can make a bootable disk or usb with Avast only and many many other tools (I didn't even list them all)! This summer, part of the team started working at Avast 19 and another part of the team maintained Avast 18 with a new minor release every week and a public release every month to cope with the frequent Windows 10 updates. Keep in mind that a new management is leading Avast and I don't know who took the decision this summer, but what I can say it's what I already said in the Avast forum months ago: we gotta focus on making sure that the last version of Avast 18 will be solid, hassle free and perfectly working before the end of the year so that we will be able to keep using Avast flawlessly as the definitions are provided in real time thanks to the streaming-updates and that only the new tools and UIs won't be available. (One of the things they'll do will be re-arranging the menu and make a sort of sub-menu for normal users and an "hidden" one for advanced users). Anyway, I don't know anyone anymore in Avast, so I can't say, but we already knew about this since this summer and we were prepared. In a nutshell: don't worry, keep using Avast, it will keep working for many years to come

@sdfox7 it was working fine in my VM and it's working fine for @someguy25 as well, however in my VM I do have all the C++ Redistributable, .NET Framework and all the POSReady updates. ucrtbase it's included with the C++ Redistributable 2015, but I can include it, no problem. New installer: Link

Sure, but that doesn't have to be a new OS. If they rolled out a new official Service Pack 4 with new tools and monthly updates and if they asked people to pay for a new licence to use it, I would have paid it and I think many people would have been willing to pay for it more than paying for a w10 licence. I'm a Linux user and I use Fedora, and I'd really like to see Windows with an updating mechanism similar to the Linux one, updating flawlessly from a version to another. For instance, if you check out the changes between Fedora 28 and Fedora 29, there have been improvements, but it feels like you are using the same OS. Same applies if you compare Fedora 29 to Fedora 26. I'm not against change. Change is good, but I don't think that Microsoft has to make a new OS with a new UI that gives a completely different user experience when they could simply update the "old" ones, trying to keep the user experience as consistent as possible.

It sends data about OS, resolution, history and installed programmes in the system to the Chinese government on a regular basis. I personally use a VPN to be anonymous, it wouldn't make much sense to use Maxthon and screw that up. It's a shame, though. If it was open source and not handled by the Chinese government it would have been a very good browser.

I had problems with Facebook using chromium 54 and a few bug using Firefox 52.9 ESR, but nothing serious. For instance, if I try to publish a link in a page and I wanna change the preview, it doesn't always work correctly. Other than that, no major issues, it's still usable.

I'm sorry, I made a boo boo. This is what happens when I test in my system only due to laziness to fire up a VM. This is the link to the installer: Link Tested and working in a VM. @sdfox7 let me know anyway. @VistaLover and @rloew yes, @Dibya made a redirect to handle calls not available in the original kernel long time ago 'cause v141_xp doesn't always output a runnable file: for instance, GetTickCount64 gets redirected to GetTickCount.

Still, it's always better to have statically compiled files that work on your system. I don't know which build you used, but I generally don't trust other people compiling it, not because of malicious intent, but because I don't know which parameters they used and which assembly optimisations they turned on as I generally use either MSVC with SSE2 or GCC targeting my own processor with SSE4. Some people managed to get better performances on Intel Parallel Studio, though, even on old hardware, but I've never used it. Still, whenever there aren't hand-written intrinsics, it all depends on the compiler ability to make them automatically: they'll never be as fast as the hand-written ones, but still. Anyway, for this build, at least SSE2 are required. If you wanna try to run it without SSE2, you can compile it yourself by disabling all the assembly optimisations in the compiler options. That should output an executable compatible with old MMX processors with plain C code instructions. As to the linking, I suggest you to turn on the static link because it's always better to include the dll. In an ideal world, you could dynamically compile and let users install and update the Redistributable. This way, you would allow users to keep the Redistributable updated and you wouldn't have to make a new release every time a security patch is released by Microsoft: as a matter of fact, your executable would benefit from the Redistributable already installed in the system, so whenever users update, your programme is updated too. Too good to be true, huh? Well, in the real world, you want to include the Redistributable in your executable for two main reasons: the first one is that not everyone have the C++ Redistributable installed on his/her system nor they keep them updated and the second one is that whenever an update comes out, you may wanna test it on your executable, 'cause it shouldn't break any functionality of your programme, but what if it does? That's my humble opinion, though. In a nutshell: whenever a programme is open source, statically compile it yourself targeting your system and CPU.

Once we'll get enough signatures (if we'll get enough signatures), we will bring it to the attention of Mozilla.

I've been playing with it a bit and it seems to work fine. The only thing I can't test is if it detects the default microphone and speakers automatically, 'cause I'm in a VM.