FranceBB

"Chestnuts roasting on an open fire CPU warming when you are cold... Windows Update running with the shield and localised updates even for the Eskimos... Everybody knows, .NET Framework and a few patch more help to make the season bright. Tiny patches, with their green check-marks all aglow will be deployed within tonight" (I just got into Christmas Mode xD)

@someguy25... That's the stable version, try the latest beta.

I think he was thinking about Windows XP Embedded, for which the support ended on January 12, 2016.

Team Viewer just dropped support for Windows XP, which makes me incredibly angry 'cause it's not like the whole programme it's not compatible, but it's just a single flipping call in SHELL32.dll (SHCreateItemFromParsingName). JeanKinzler from support stated So I opened my own ticket (If Team Viewer was open source, I would have coded an alternative to that call myself.): https://community.teamviewer.com/t5/TeamViewer-General/Missing-function-call-in-TeamViewer-14-0-13880-Windows-XP/m-p/50142 "TeamViewer.exe" looks for "SHCreateItemFromParsingName" in "SHELL32.dll", but that function doesn't exist in Windows XP as it has been introduced in Windows Vista. SHSTDAPI SHCreateItemFromParsingName( PCWSTR pszPath, IBindCtx *pbc, REFIID riid, void **ppv ) SHCreateItemFromParsingName is a function that creates and initializes a Shell item object from a parsing name. Its parameters are "pszPath", which is a pointer to a display name, "pbc" which is optional and it's a pointer to a bind context used to pass parameters as inputs and outputs to the parsing function, and "riid" which is a reference to the IID of the interface to retrieve through "ppv" which contains the interface pointer requested. If you use Team Viewer, please reply to my ticket in order to raise attention.

I hate viruses too. In an ideal world, antivirus softwares wouldn't exist and we wouldn't waste resources. Unfortunately, there are thieves on the high street and there are thieves on the web. On the top of that, instead of living in in harmony all together, different countries have different views on different things and they often disagree and these views lead to international conflicts, which is why there are terrorists spread all over the world and intelligence agencies like NSA and MI6 that actually make viruses to spy enemies and to protect their citizens and there are criminals that make viruses to steal credit cards and so on. Will we ever agree and live in harmony in the whole world? Probably not as it's a utopia, but in all this darkness there's a little shining ray, 'cause here in MSFN there are people from different countries and we all respect each other and try to help each other, which makes me think that maybe, just maybe, one day, human beings will refrain from being greedy and will cooperate (but I'll probably be long gone into dust before this happens). (end of off-topic).

Definitely false positive; we would never release a virus. (Not like this, not to this community).

You are right, our version of XP is pretty heavily modified and our virtual machines don't always behave like physical ones do, but I don't have a "normal" XP SP3 installed in a physical machine. Since you are pointing it out, I take the chance to tell everyone that we have a group on Skype in which we organise things to do, so if someone is willing to help us testing or coding and so on before posting the results here on MSFN, feel free to tell us and we'll add you. Out of records, this is something we do in our spare time, and it's actually done in a bit of a rush as we are all very busy (me, Dibya, Samuel, Peter). If they were official projects, they would have been organised on VSTS (Visual Studio Team Services), with a track of every change, every commit, recorded test sessions and so on, but they are not and everything is a bit of a mess. On the top of that, only Samuel works as a Full Stack Developer; I mean Peter is more of a system admin than a programmer (but he's studying how to code), Dibya is a junior developer and he is trying to do a lot of things driven by the passion he has (and he's still improving year by year) and I do something completely different for a living as I'm a broadcast engineer, specifically I'm an encoder: I encode programmes to make sure that they are ready to be put on air (Luma and Chroma are in range, audio is at -24LUFS, there's no noise, no aliasing, no ringing etc by writing scripts in a pseudo code close to C). I know that it might sound like "oh, so you actually are a programmer" and the answer is "yes, but as long as it's AV related, I'm fine, but if it's not, I'm not that good and on top of that, I suck in writing intrinsics, for instance". In other words, it's a pretty "weird" group, but we all share the same passion for XP, even though for me it's becoming something more "academic", just to see what "can be done" as my main OS is Fedora (Linux) and I do many other things on Windows Server 2019, and at work I have W10 on all my workstations (I mean, I don't like it, but I can live with it, 'cause work is work and it's all about getting things done).

Not necessarily. The app calls a fake kernel32 which redirects the call to kernelxp which is included in the package. Weird, 'cause it's there: I tested it on a clean system too and it works. @Dibya can you test the install (just to confirm that it's working)?

By the way, I just installed it on a freshly created virtual machine which has all the POSReady updates and it works flawlessly: This is my system instead:

On their website, they state that XP is supported, but when I downloaded it and tried to run it, I got the same message you got: Let's see who is to blame... Uhm... ADVAPI32.DLL which calls RegGetValueW. A function that retrieves the type and data for the specified registry value. LSTATUS RegGetValueW( HKEY hkey, LPCWSTR lpSubKey, LPCWSTR lpValue, DWORD dwFlags, LPDWORD pdwType, PVOID pvData, LPDWORD pcbData ); "hkey" is used to open registry keys, "lpSubKey" is the name of the registry key, "lpValue" is the name of the registry value, "dwFlags" is a flag to define the data type of the value (REG_DWORD, REG_BINARY, REG_QWORD ecc), "pdwType" is pointer to a variable that receives a code indicating the type of data stored in the specified value, "pvDat" is a pointer to a buffer that receives the value's data, "pcbData" is a pointer to a variable that specifies the size of the buffer pointed to by "pvData". According to MS documentation, the function is available on Windows Vista. And "abracadabra": mIRC 7.53 Windows XP: Link Cheers.

@Dave-H could you share the whole log file? Have you disabled some Windows Services? Please note that some of them are required by Avast to work properly (I remember a customer complaining that the automatic update screwed up his install, but it really was just because of a service not running). Please use the official Avast cleaner to remove every trace of the programme, reboot, download the latest offline version and make sure that you are online when you are doing the installation. After everything has been installed, reboot. After the first reboot, it might not load properly, but it's fine as it's trying to load all the modules. Then, reboot again. This time, if it doesn't work, I'll send you an executable to make a full system report (it's the one I used to run when I encountered problems and I had to report them). As to the POSReady updates, no, they are not mentioned in the forum for obvious reasons, but during the tests on VMs, incompatibilities have been checked against an updated version of XP. The only stage in which there were issues was during the beta and some release candidate, but almost never in the stable version and definitely never in the latest one. Last but not least, do you have at least the .NET Framework 2 installed? If not, install it.

The way I tested wasn't by installing additional modules, but unpacking it to C and trying to run a programme using the new Python Redistributable and it actually worked. I used a simple script to grab video and audio from a stream using rtmp via Python. I didn't test it with any other scripts and I didn't try to install any additional components, but I wouldn't be surprised if they don't work. It is a backported version after all, but as far as "runtime executable", it works fine.

I'm the same person; I knew people working there and I used to talk to them, and be unofficially informed about the development in summer 2015 'till the very beginning of 2016. As a matter of fact, I still think that Avast 16 was one of the best UI and programme version. After that, I haven't been involved in anything and when a new management got the company the people I knew started to be less and less 'till now, the moment in which I'm not even a beta tester anymore (but I'll have the "sticker" beta on the latest stable version of the programme forever as a memory). A few pictures ("old-goodies", actually) from 2015, which seems like an eternity ago already:

Precisely. C'mon people, sign and share.

Install the latest version available for XP of the K-Lite Codec Pack and install PotPlayer / MPC-HC. They are light and very powerful players, way better than VLC and they'll let you choose which renders to use (D3D9, Haali, MadVR, OpenCl) and the hardware acceleration (DXVA2-copyback, Intel QuickSync, NVCUID etc). They will also let you choose whether you want post-processing or not, like linear interpolation (which is like the true motion function on TVs), Denoise, Debanding and so on via frameserver (Avisynth) and many other options. PotPlayer and MPC-HC are way more tweakable than VLC and other player and with the K-Lite Codec Pack (which includes LAV Filters) you are good to go.

@someguy25 and @Mathwiz I bet you were looking forward to see this. It works fine on my machine and on Dibya's one. A big fat thank you to both Dibya and Samuel (Samuka).

I love and hate Chromium at the same time. I didn't like the decision Google took to remove support for XP and Vista, especially 'cause the project is open source, but only for the things they like. Open-source developers who published commits had no say on this whatsoever (there were many devs that were willing to drop XP support, of course, but there were others that didn't want to as well). Anyway, even if I didn't post on MSFN my failures, I tried to backport Chromium several times during these years. It's a project I hate, 'cause I always end up starting it, then I find something that has to be re-implemented, I do it, but I either break it or produce a several number of bugs, then, after fixing those bugs, I end up having memory leak issues and once I get them sorted, I go on with the code and I find another thing that has to be re-implemented. In the meantime, things changes, new commits are done and so on, but even if I stick with an "old" version, it just doesn't work. Eventually, I end up giving up and going back to it after a few months, then I give up again. @Dibya knows that, as he tried to backport it several times as well and we shared informations on Skype, but we both failed. (For instance, I never got the sandboxing working). "Taokaizen" actually made a project with a backported Chromium 54, though, but it's not exactly Chromium 54, it's more like a "best of", a "mesh-up" of Chromium 54, Chromium 51 and Chromium 49, with parts of the code replaced entirely. I give credit to Taokaizen, anyway, 'cause he did manage to get it working, however there's still a call to a non-existent kernel function on the settings page (instruction 0x04d670ed referenced memory at 0x00000000. The required data was not placed into memory because of an I/O error status of 0x75b2b11c), pepperflesh implementation is broken, it has some concerning memory leaks and it calls WNetRestoreConnectionA and SHGetKnownFolderPath when it's not supposed to. In other words, it has some issues, but it works. @VistaLover... if you wanna take a look at the source code patched by Taokaizen, it's here: http://browser.taokaizen.com/download/patch.txt - build by Taokaizen http://browser.taokaizen.com/download/Advanced_Chrome_v54.20.6530.0.zip It doesn't re-introduce Aero for Win Vista, though and he's not planning to release any new version for XP/Vista. If only @blackwingcat was still around...

I'm downloading the SP3, even though I don't know whether it's a good idea to install the SP3 with all the updates I have, but I'll try. Anyway, I noticed that right now, even with "just" the SP4, when I boot in safe mode and I log as Administrator, pretty much everything is in English already, however when I log as FranceBB (my account) the majority of the system settings are in Italian. That's weird... For instance, if I open the task manager as Administrator, it's in English, if I open it as FranceBB it's in Italian.

Ok, the system is up and running, however it's... uh... "hybrid". Some menus are in Italian, some others are in English. I installed the SP4, 'cause Harkaz wrote in the topic that "Windows XP SP4 can installed on any version of Windows XP with SP1", which led me to think that SP4 actually includes SP2 and SP3.

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...