FranceBB

Still no luck with FileZilla on my side... I solved a few errors, but there are still 13 errors.

Updated link with static linking. Edit: updated post with the link to the official version. Victory!! They will support XP again!

@Stefan43... for the same reason why companies spend a lot of quids for softwares like Adobe Premiere, Final Cut etc instead of downloading a crack. Basically, if you work in a company and you run cracked programs or you use invalid licences, you can be fined up to 100k £ (worse case scenario). By the way, the XP paid support is called "premier support" and you can ask Microsoft here: https://www.microsoft.com/en-us/microsoftservices/support.aspx Anyway, despite the fact that we are getting the POSReady updates for free, since the OS is slightly different (it has less functionalities), it would be interesting to know whether Microsoft has released different packages for the premier support compared to the POSReady ones. Think about it. Since in the POSReady version some functionalities are disabled, they can't be used by hackers as "gateway", but what about XP? Besides, it would also be interesting to know whether Microsoft would be interested in keeping the premier support after 2019 or not.

Thanks to several people asking for XP support, developers are now officially supporting XP again (at least SSE2 capable CPUs): https://github.com/FFMS/ffms2/releases Old post

I'm still using XP and I'm not going to switch. It's October 2016; summer 2018 it's still far away. Besides, the compatibility layer may bring "fresh air" to XP in a long term run. As to the security updates, we'll be fine 'till 2019, so there's nothing to be worried about.

I didn't play any games for years, to be fair. I don't have any games in my computer nor in my mobile. I used to play with both consoles and computer when I was a little boy. My passion is the encode and that's the way I use to have fun (with avisynth, its instructions and creating graphic FX in LUA with Aegisub). Can't help you this time, sorry about that. :|

@Mcinwwl... yep. Anyway, I tested it with a program and it works. Dunno whether some functions won't work, though.

Yep. I think he was talking about this: https://mega.nz/#!rNVSFCQB!eAh54cJVzmCR7nXEHTRh9GHa11agGBsLR_lM_fkG26Y It's a different implementation which doesn't use OpenGL as Wine does. Although it used to be very good, it works with NVIDIA GPU but we didn't have luck with ATI/AMD GPU. That's why people generally use the Linux based version (Wine).

Hi folks! Python (multi-platform programming language) officially dropped its support for Windows XP. Python programs are slightly different compared to other programs, because they are not compiled when you download them: they are just scripts. When you click on them, they will look for Python "assemblies" in order to quickly compile the program during the runtime. (It's not 100% true, but that's an over-simplyfied explanation). So... since Python dropped its support for XP, this meant a big issue for Python programs 'cause the old "assemblies" can't compile 3.5 scripts; that's why Python 3.5 Runtime Redistributable - Windows XP is here for you. Please note that this is an unofficial Runtime Redistributable package. Extract it to "C" and rename it "Python35". The core and its dependencies have been compiled to run in Windows XP, but I have been able to test with a single program 'cause I don't have any other programs written for Python 3.5. You'll find the official Python website screen and the backported version below. Link

Hold on, buddy.

By the way, IE8 likes "bitching" (can I say that or is it considered a bad verb?) while checking for newer updates via active x. Sometimes I just have to click and it finds all the updates without any issues, while some other times I had to click it twice to get it working... it's pretty normal

@JodyT... I tried Windows Vista, 7, 8, 8.1 and Windows 10; yet, my favourite OS is Windows Server 2008 R2 for business related stuff, and XP as home and daily usage. Anyway, Windows XP uses old APIs and is missing several functions, like the one which allows you to receive push notifications from apps/programs on your computer as it was your mobile. There are many other functions that have been added in newer OS, but many of them are actually made to have an OS as close as possible between mobile and desktop. Do you actually really need them in a desktop environment? No. Besides, I don't like the new Microsoft policy of a "packed Pc ready to use", which resembles the Apple style. They want to release an OS as simple as possible to use for the common users, removing and blocking certain things in order to prevent users from damaging the OS itself. One example? Microsoft did include the Classic style in Windows 10, but blocked it by purpose because MS guys wanted people to get used to a single UI... Do you get where I'm coming from? Anyway, let's stay in topic and talk about Firefox. Even though their decision is quite possible to understand, I wouldn't actually like to have XP moved to the ESR branch so soon. Maybe we should encourage people to have their say in the Firefox page, so that we can convince them to keep supporting XP.

Mono has almost every but not all the features that .net 4 offers. For instance, "CodeContracts - API complete, partial tooling" and "Server-side OData - Depends on Entity Framework". Anyway, they have been implementing C# 5 and 6 released with the .net 4.5 and 6, even though, despite the fact that the asynchronous base class library has been defined, asynchronous mode in MVC 4 and 5 is not supported.

Yep, that one. It's one of the best video indexer ever made. There are many video indexer like LAV, DGI etc, but ffms2 (ffmpegsource2) is my favourite. Problem is that they didn't include all the headers needed in the master project in github, so I'm manually adding them, which is a pain in the butt. Anyway, I should be able to compile it without any issues with Visual Studio 2010 (no need to use GCC this time). As to the .net framework, I'm still disappointed with Microsoft: they released the .net core claiming that it's cross platform, but despite the fact that it does work on Linux, they totally didn't care about Windows XP. Side note: I was talking with some Microsoft guys in the MVA last time, and they told me that Microsoft developers lurked a lot in forums during the past few months about .net related things, to understand what users want and what they could add, and I wouldn't be surprised if they actually read topics in MSFN as well...

@TuMaGoNx... it works, even though the programs I tried to patch failed to load. I think that's fine for programs which have been blocked by purpose on XP, since it modifies the system version number to 5.1 and it's easy to be used by users @dibya... got it. By the way, I'm making progress with Filezilla and ffms2

@Dibya Local Security Authority Subsystem Service; it verifies credentials; basically it's the service which prompt you to the login screen and then to the desktop. The weird thing is that it runs fine in the virtual machine, but it doesn't on your machine... What your machine has compared to the virtual machine is: A) CPU Instructions B) more RAM So... since I don't actually think that instructions affect the kernel in this case, I would say that the PAE mode activated with the custom ntdll included in your kernel doesn't work as it should. Did you actually try to disable it, trying to run XP with your modded kernel but using the normal mode? If it's already disabled, then I don't actually really know... :| @TuMaGoNx... I've downloaded it, but I didn't have time to test it. I'm gonna try it later this afternoon. In the meantime, I'm working on backporting ffms2 and Filezilla. I already solved many things and I'll release them as soon as I can.

Everything installed fine. @glnz there's nothing to worry about installing POS updates anymore, even 'cause we didn't have any issues so far, excluding long time ago when an update screwed up the fonts...

@TuMaGoNx... as to chrome, we downloaded the source code and we have been "studying" it as well; it's not what they added, but what they removed instead... when they released the new version which didn't care about XP and Vista, they removed significant parts of code related to XP, trying to make the code more light and simple... As to the system, something automated would be better, as Dibya said. That's mainly because, even though you are going to "touch" the system, it's gonna be a way easier for users... We are familiar with CFF Explorer, IDA Pro, Dependency Walker etc and that's fine, but many people here don't even know how to recompile a program... if you release something that needs users to do certain things, many of them won't be able to use it, or may just give up using it... After all, people should be able to use an OS, without knowing certain things... that's why BWC released what he released... Anyway, that's my opinion, but feel free to keep working on your idea as we need different implementations Just... "keep It simple".

@TuMaGoNx... there are two different implementations to be fair, the one released by KM and the Wine one, which uses OpenGL and that we inherited from Linux. I tried both of them as well as Dibya. @Dibya yep, unfortunately the KM ones are pretty old and far from being perfect; the other solution is more reliable. Including WineD3d - as you did - was the right choice

D3D11 ain't a big deal 'cause both Direct X 10 and 11 have been backported to XP already. As to the WMF (Windows Media Foundation), this may be a problem, as it has been introduced in Vista to replace DirectShow APIs, like ACM and VfW... Besides, it has its own process/service called MMCSS to handle the amount of resources to dedicate to audio/video operations... this may be a pain in the butt to backport...

@TuMaGoNx... I'll take a look at your code on GitHub next week (I'm kinda busy at work, right now) and I'll let you know. I'm kinda curious about your own implementation now. @dibya... go ahead that way, but take a look to his project as well, as we may be able to collaborate all together, which would be awesome.

@Dibya you have a PM. Besides, here is a more accurate list. Feel free to PM me back. I wrote it here so that if anyone knows something about these functions can contact us. GetApplicationRecoveryCallback, GetApplicationRestartSettings, GetProductInfo, GetThreadPreferredUILanguages. GetThreadUILanguage, K32GetMappedFileNameW, K32GetModuleFileNameExW, QueryFullProcessImageNameW, WerGetFlags, Wow64DisableWow64FsRedirection, Wow64RevertWow64FsRedirection, DeleteProcThreadAttributeList, InitializeProcThreadAttributeList, EtwEventWriteNoRegistration, EtwGetTraceEnableFlags, EtwGetTraceEnableLevel, EtwGetTraceLoggerHandle, EtwRegisterTraceGuidsW, EtwTraceMessage, EtwUnregisterTraceGuids, NtAlpcConnectPort, NtAlpcSendWaitReceivePort, NtApphelpCacheControl, ShipAssert, WinSqmAddToStreamEx, WinSqmIncrementDWORD, WinSqmSetDWORD, WinSqmSetIfMaxDWORD, GetProductInfo, QueryFullProcessImageNameW, WerGetFlags, strcat_s, strcpy_s. By the way, I'm getting some weird things going on. Windows XP does support C++ Redistributable 'till the 2015 one (the very last one released), BUT I'm getting errors related to the MSVCRT library which should be updated. I assume that Microsoft released a different version of MSVCRT for XP, as it doesn't have _except_handler4_common, _vsnprintf_s, strcpy_s, strncpy_s. For everyone: please note that an OS is not just made by a kernel, but has different APIs managed by: Hal.dll, NTDLL.dll, Kernel32.dll, Gdi32.dll, User32.dll, Comctl32.dll, Ws2_32.dll, AdvAPI.dll, NetApi32.dll, Shscrap.dll, Winmm.dll. These are SYSTEM DLLs which have SYSTEM APIs inside, used by different programs and they have all been updated in newer OS. Then, there are the C and C++ runtime libraries which are installed via the C++ Redistributable: MSVCRT.dll, MSVCP.dll, CRT.dll which I still don't know why the XP ones don't have certain functions... did Microsoft block them in XP by purpose? And why? And then, "dulcis in fundo" (last but not least), the .NET, which includes Microsoft Foundation Classes relying on the MFC.dll (XP has the MFC 10.0.40219.325 - August 2011, while newer Windows can run the MFC 14.0.24212.0 - August 2016), so we have the mfc100.dll, instead of the mfc140.dll, the mscorelib.dll, the System.Windows.Forms.dll and others...

I'm going to work, but I will send you a PM tonight.

Of course they are. The x64 is slightly newer and slightly different. Please note that "slightly" for Microsoft means "very" for us, as we still don't know how many things work. I really wish to see the source code of XP, but unfortunately, since it's a copyrighted OS, we will never have the chance to see it. Besides, we didn't have a clue back when we started studying the XP kernel, but thanks to people sharing their knowledge, we managed to understand some parts of it. Unfortunately, "reverse engineering" is the only way to get how things work, but I failed several times with many decompilers, disassemblers and hex editors. The same goes for Dibya who tried several different approaches with several different ways and programs and who is still trying to figure out certain things, but he is doing a great job and a huge effort, and he is definitely moving forward, bit by bit. In the meantime, I kept working on the .net framework on my own, but I'm getting closer to a dead end: assemblies using API calls as dependencies for certain tasks which, unfortunately, are not in XP. In other words, if everything goes well, I'll be able to really make the newer . NET frameworks work in XP, BUT certain functions won't and programs may break or be corrupted out of the blue.

These kind of projects generally require a huge amount of work. Doing it for two kernel? Not gonna happen unless you are a Microsoft engineer. :|