FranceBB

You mean ReactOS? You can try it, but it's nowhere close to a proper fully functional and updated OS, as its compatibility is Windows 2000/Windows XP, while it should really be at least Win7 to be considered functional these days. Anyway, I do understand that it's really difficult for developers to develop ReactOS without infringing any copyright, that's why it's very much based on Linux implementations like Mono and Wine that have been developed for years, but are still far from being perfect. An antivirus software that does its job is required as well. Whenever other people connect to your computer for any kind of reasons (like p2p) or whenever you visit a new website that you don't know or whenever one of your friends/coworker/family members/existing human being plugs in a USB Stick/Hard Drive there's a chance you can get infected. I strongly suggest you Avast, which will cover up any eventual new security issue, but keep in mind that an antivirus is not a cure for security vulnerabilities: if a new vulnerability is found and support is over, it will never be patched, which means that the Antivirus will try to block any threat that tries to use that vulnerability, but if it doesn't, the threat will successfully exploit it. There are rumours about the Microsoft Premium Support program. This type of support is aimed to keep businesses secure with constant support from Microsoft engineers and updates for the products used (to a certain extent). Will it include Windows XP and Server 2003 machines? It's likely Microsoft will continue to support XP and its derivatives as they are already supporting it (remember that businesses using XP weren't able to apply the POSReady registry entry and they are paying Microsoft for the Premium Support). In a nutshell: - Will Microsoft still support XP? Yes, it's very likely they will via their Premium Support program. - How much will it cost? You can ask Microsoft yourself by requesting a price quotation for your business at Microsoft, but it seems that it's going to be around $15000 per year. - Can a private and not a business apply? I have no idea, ask Microsoft. - Is it worth it? For private people who don't own a company like us, I think it's not. - Are there going to be exceptions? There might be exceptions if the security vulnerability found is really important and they might release an update for us all for free as they did for WannaCry. (But this is my assumption, so there's no guarantee they will). - Is there a chance that updates will be leaked by a hero wearing a cape? Very unlikely, as it would mean the immediate loss of support by Microsoft, a significant fee and prosecution. Nobody would be so stupid to risk it and even if some miracle patch appears by someone unknown, would you trust it? (I wouldn't). Last but not least, the main problem for XP users will be the compatibility with newer protocols like TLS 1.3, certificate handling like ECC, the new version of the .NET Framework, the .NET Core and so on. These are highly unlikely they'll ever be ported on XP, despite the fact that Microsoft said that they were working on supporting ECC months ago, but they kept it quiet and they didn't really talk about it, which makes me think that something went wrong down the road. I'm an encoder and a developer myself and I find incredibly difficult to support XP nowadays unless you are using C++ or using old version of a programming language like C#. For instance, I generally develop Windows programmes in C# using Windows Form and targeting .NET Framework 4, which is XP compatible, but not only new features of C# and SQL don't support XP, Microsoft doesn't even encourage to develop using it anymore as it wants you to use UWP with C# and XAML, using the .NET Core and Blend (for design) for cross platform compatibility at the expense of breaking compatibility with old version of Windows 10 (Legacy Windows like Win8.1 and lower are not supported). I've been recently asked to develop a programme this way so that they were able to distribute it as an App for tablets and phones. What about XP? Well, it will die a slow death as you will still be able to use it up to a point in which it will become unusable as nothing will work on it and even opening a simple internet page will almost be impossible.

LONG64 InterlockedCompareExchange64( LONG64 volatile *Destination, LONG64 ExChange, LONG64 Comperand ); The function compares the "Destination" value with the "Comparand" value. If the "Destination" value is equal to the "Comparand" value, the "Exchange" value is stored in the address specified by "Destination", but since the function has been introduced in Windows Vista, on XP no operation is performed, which basically means that Team Viewer *will* run, but every "Comparand" will be considered a mismatch, which means that it might behave unpredictably. Anyway, since it's closed source, I don't know where that function lies in the code and what they use it for. Still, you can just redirect it to the normal InterlockedCompareExchange which is supported on XP: https://docs.microsoft.com/en-us/windows/desktop/api/winnt/nf-winnt-interlockedcompareexchange Last but not least, people, please, reply to the ticket I made to raise awareness to the Team Viewer team! https://community.teamviewer.com/t5/TeamViewer-General/Missing-function-call-in-TeamViewer-14-0-13880-Windows-XP/m-p/50142

LONG64 InterlockedCompareExchange64( LONG64 volatile *Destination, LONG64 ExChange, LONG64 Comperand ); The function compares the "Destination" value with the "Comparand" value. If the "Destination" value is equal to the "Comparand" value, the "Exchange" value is stored in the address specified by "Destination", but since the function has been introduced in Windows Vista, on XP no operation is performed, which basically means that Team Viewer *will* run, but every "Comparand" will be considered a mismatch, which means that it might behave unpredictably. Anyway, since it's closed source, I don't know where that function lies in the code and what they use it for. If you experience any "weird" behaviour, report it here, please. Last but not least, people, please, reply to the ticket I made to raise awareness to the Team Viewer team!

Yes, my bad. I'm doing many things at the same time and I didn't rename it. I'm glad you figured it out yourself, though. As to the look, well... I can't blame the MKVToolnix developer, 'cause the fault is to address to the QT development community. MKVToolnix is cross-platform and can be compiled for Linux, so the developer had to use one of the graphic environments available on Linux. The QT community also has a Windows branch and the developer is just following the good practice of using the latest version of the library; too bad the linux community broke XP with the new-ish version of the library. I could potentially link against the old QT and manually change the code that is not compatible in order to compile the last GUI for XP. Doable? Probably yes. Worth my time? Probably not. But if someone wants to, he/she can go back to the pre-2015 version of QT and check what they changed 'till not.

Add me on Skype: francebb1 - franceopf@gmail.com and I'll add you to the Windows XP Forever group, you'll find Samuel (Samuka), the developer of One Core API. https://join.skype.com/upSJ1SDTscvd Once again, we cannot link nor guide you to use anything related to a modified kernel on MSFN as it uses modified version of Windows DLLs.

No, it's actually the memory I allocated, as I have Linux (Fedora) as my main system and all the other OS are just Virtual Machines. My XP is slightly different as it's a physical hard disk with a physical installation of Windows that I've copied year after year, but it's fired up by a virtual hardware. Anyway, I tested it with 10.5 GB of RAM so far and it was absolutely fine. Just install the russian patch I sent you via PM. And please, make a Skype account so I can add you to the XP Forever group.

We are living on borrowed time and steady we go towards our beloved OS death. It's been a great journey and it's close to the end, but my fellow XP users, don't be sad for what is not going to be, be happy for what it's been. :')

2018 is almost over, 2019 is quickly approaching and you know what's gonna bring 2019? New version of Visual Studio and Intel Parallel Studio, which basically means new version of C++ Redistributable. Intel already released the new Intel C++ Redistributable and they are compatible with Windows XP, so a big fat "thank you" to Intel. As to M$, the Microsoft C++ Redistributable 2019 have not been released yet, as Visual Studio 2019 is still in beta, but I hope they'll support XP. https://software.intel.com/en-us/articles/redistributable-libraries-for-intel-c-and-fortran-2019-compilers-for-windows

https://gitlab.com/mbunkus/mkvtoolnix We have quite a few components with calls not available on XP In order, we have IPHLPAPI missing ConvertInterfaceIndexToLuid, ConvertInterfaceLuidToIndex, ConvertInterfaceLuidToNameW, ConvertInterfaceNameToLuidW KERNEL32 missing CancelIoEx, GetFileInformationByHandleEx, GetTickCount64 (For which I'm just gonna use the normal GetTickCount), GetUserPreferredUILanguages, InitializeProcThreadAttributeList, DeleteProcThreadAttributeList SHELL32 missing SHCreateItemFromIDList, SHCreateItemFromParsingName, SHGetKnownFolderIDList, SHGetKnownFolderPath, SHGetStockIconInfo, SetCurrentProcessExplicitAppUserModelID, Shell_NotifyIconGetRect MPR missing WNetRestoreConnectionA (for whatever reason, but it's not important) USER32 missing ChangeWindowMessageFilterEx, CloseTouchInputHandle, GetTouchInputInfo, IsTouchWindow, RegisterTouchWindow, UnregisterTouchWindow, UpdateLayeredWindowIndirect UXTHEME missing GetThemeTransitionDuration Unfortunately, there aren't work-around available for all of them, mostly because the GUI uses the QT cross-platform interface which is not XP compatible as it dropped support a while ago and it gets worse day by day, breaking compatibility even for simple things like the fonts in QWindowsFontEngineDirectWrite and disabling DirectWrite doesn't solve the issue; leaving the old GUI and just compiling the new components targeting XP worked, though. I'll make an installer soon. EDIT: There you go: https://mega.nz/#!GJcmUS6R!FvWCCGWxStx5_23MSSJ8l_PC0eJOPaGFaMRtN2XTZFM

Fair enough, there you go: Well, yes, that's what I meant. ^^

It's not that I don't care; I could send you the link to download the Chinese patch or the Russian patch straight away, but I would rather not be banned. There are rules and we can't just do whatever we want and redistribute protected softwares or modified version of the official DLLs made by Microsoft. In order to get 64GB of RAM, the patches use a modified HAL (Hardware Abstraction Layer) which talks to the hardware at 36bit and to the software at 32bit. This way the kernel can execute 32bit programmes (that can use up to 2GB each) and can allocate as much memory as the system has. The reason why Microsoft limited PAE to 4 GB on consumer systems was that many consumer drivers were misbehaving as they weren't designed to work with PAE. Check your PM.

Can you share the modified installer via PM so I can archive it?

There are two patches: one is a backport of the official DX11 done by a Russian team (the same team that backported DX10), the other one is a wrapper for OpenGl. The thing is that the backported version has never been finished and it has a very limited compatibility with games. Besides, the Russian team that was working on it dropped the project. As result, @Svyatpro and others ported the Linux implementation to XP: on Linux DX10/11 games go through a wrapper which translates the calls to OpenGl, executes them with the GPU and then it translates it back. Although OpenGl is a fairly good protocol and the translated calcs are "just" Single Precision Floating Point which are perfectly handled by the GPU (both AMD and NVIDIA) due to the large number of 32bit capable units in consumer GPUs (there are a lot of single precision units and half precision units in consumer GPUs and just a few double precision units), unfortunately translating calls back and forth slows the whole thing down. In other words: does it work? Sort of. What do I do if it doesn't? Either help the project yourself or nothing. My memory might not be perfect, though, but I'm pretty sure this was the situation 'till a few years ago, before people started forgetting about it. P.s I don't play games; last time I did was many years ago and I've never been a gamer; the only reason why I use a GPU (other than display a video) is to use OpenCl to speed up Discrete Cosine Transform and Fourier Transform calculations. In other words, I couldn't care less if the latest DX prevents a game from running on XP as I wouldn't be playing it anyway...

AVG and Avast share the same core, but they have a different front-end ever since Avast bought AVG. I'm speechless, 'cause the UI used by Avast is just a C++ front-end compiled with SSE2 assembly optimisations targeting XP as well and it shouldn't have anything fancy inside. It should be slow-ish (on some systems) and not scalable (which makes it difficult to use on low res systems) but it shouldn't break. Besides, even if the UI doesn't work for whatever reason, the core and the protection engine should as they take the configuration from the configuration files and only the final integrity check should misbehave. In other words, the worst case scenario I was thinking about is the UI process using up all your resources trying to load itself up. The worst thing is that I can't reproduce it neither on my computer nor on a VM. Do you have Skype? Can you add me? (francebb1 - franceopf@gmail.com). On one hand, I'd like to find out more about the issue in order to solve it once and for all, on the other, since I no longer have any affiliation with Avast and AVG shares its protection engine, I would tell you: "if it works, leave it as it is". It's up to you; if you are willing to test a few other things (unofficially), add me on Skype and I'll add you to our group chat. (Dibya, Peter, Samuel... we are all there).

I'll take a look at the source code for the next version in a few days. Right now, I'm just gonna lay on my couch (and then on my bed), trying to digest the turkey. Merry Christmas. ^^

I don't get it. What I did was: 1) Removing all the former rules sudo iptables -F 2) Denying everything sudo iptables -P INPUT DROP sudo iptables -P OUTPUT DROP sudo iptables -P FORWARD DROP 3) Accepting the loopback sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A OUTPUT -o lo -j ACCEPT 4) Allowing internal networking (i.e connecting to my router) sudo iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT sudo iptables -A OUTPUT -d 192.168.1.0/24 -j ACCEPT 5) Enabling openvpn port udo iptables -A OUTPUT -p udp --dport 1194 -j ACCEPT sudo iptables -A INPUT -p udp --sport 1194 -j ACCEPT 6) Enabling the VPN Server ip address sudo iptables -A INPUT -s xxx.xx.xx.xxx -j ACCEPT sudo iptables -A OUTPUT -d xxx.xx.xx.xxx -j ACCEPT 7) Enabling tun0, which is the internal connection to the VPN sudo iptables -A OUTPUT -o tun+ -j ACCEPT sudo iptables -A INPUT -i tun+ -j ACCEPT It actually works for my computer and as soon as the VPN connection drops, all the traffic is blocked, which is fine, but when I share my connection using Linux as Wi-Fi hotspot, the devices connected to it can connect without VPN if tun0 goes offline, which is exactly the same situation I had before with UFW... I need all wlp2s0 to use tun0 only as its source of traffic. I tried with sudo iptables -A FORWARD -i tun0 -o wlp2s0 -m state --state RELATED,ESTABLISHED -j ACCEPT but it's the same... sudo ifconfig -a enp0s20f0u5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.114 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::81d2:ca64:9358:261d prefixlen 64 scopeid 0x20<link> ether 06:e1:fe:ad:3b:8a txqueuelen 1000 (Ethernet) RX packets 51969 bytes 34961450 (33.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 54430 bytes 29211706 (27.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 enp3s0f1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether 70:4d:7b:46:72:a7 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 238 bytes 20064 (19.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 238 bytes 20064 (19.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 pan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.59.70.11 netmask 255.255.255.0 broadcast 0.0.0.0 inet6 fe80::34b6:bcff:fe0a:3f4b prefixlen 64 scopeid 0x20<link> ether 36:b6:bc:0a:3f:4b txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 245 bytes 10834 (10.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500 inet 10.8.8.201 netmask 255.255.255.0 destination 10.8.8.201 inet6 fe80::65bd:f28a:9ac:3e3a prefixlen 64 scopeid 0x20<link> unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC) RX packets 1099 bytes 531983 (519.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1114 bytes 149277 (145.7 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 52:54:00:c9:d0:a4 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0-nic: flags=4098<BROADCAST,MULTICAST> mtu 1500 ether 52:54:00:c9:d0:a4 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.42.0.1 netmask 255.255.255.0 broadcast 10.42.0.255 inet6 fe80::bca5:7f7b:cbec:5bd3 prefixlen 64 scopeid 0x20<link> ether e2:74:fa:a9:36:4b txqueuelen 1000 (Ethernet) RX packets 25386 bytes 22922627 (21.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 20010 bytes 7900762 (7.5 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Ok, I'm gonna send you the link via email. All the executables are digitally signed by Avast, so you can totally trust them (feel free to check ^^). Step 1) Use "avastclear.exe" to get rid of every file, folder, setting and registry change made by Avast. Step 2) Reboot. Step 3) Go to Start, Control Panel, Administrative Tools, Services and make sure that "Background Intelligent Transfer Service" and "Terminal Services" are set to "Automatic" and have started. If they are disabled, make sure to enable and start them. Step 4) Make sure you have the latest .NET Framework and C++ Redistributables installed. If you don't, install them and reboot. Step 5) Apply the registry patch and reboot. Step 6) Install Avast 18.8.2356 free using the installer provided making sure that you are running it as Administrator. Step 7) Protection services may not start and you might have issues with the UI, but that's "normal" on some systems. Just give it some time and then reboot once again. Step 8) After you rebooted, open "avastsupport.exe" and run it. It's gonna automatically check the integrity of the installation and it should report everything with the word "SUCCESS" in green. If it doesn't, click "next". In the next screen, provide the email address of your account and write down all the steps you took before the error happened. This way, a new ticket is gonna be created, but this time it will report everything about your system (but with a bit of luck we won't get there). If you feel comfortable enough to "trust me" and something goes terribly wrong, let me in via Team Viewer.

i7 6700HQ 4c/8th 2.60GHz, 16GB (8x2) DDR4, 2TB HDD Sata III (1TB + 1TB), NVIDIA 950M GPU. No crashes and it's a fairly new system (January 2016).

Not sure which one you are using. Try installing the latest One Core API on a working system: Source: https://github.com/Skulltrail192/One-Core-Api - Build <redacted> (Note for Dencorso: it's GitHub and the project is open source, so I don't think there are any issues, but if there are, please let me know).

Team Viewer 14.1.6265 Beta working on Windows XP... Well... Sort of... Unfortunately, I can't share it 'cause TeamViewer is not opensource and redistribution of modified software without authorization is not allowed. (I don't wanna get another warn by Dencorso as I got a year ago). Let's see how long it's gonna last. I'll keep you updated.

Yes, it supports demilitarized zone.

It will work for quite some time. Nonetheless, it won't work sooner or later... and considering how Microsoft is behaving these days, it might stop working sooner than expected. Time will tell.

I was wondering why I received an update today, but I thought it was something that failed to install for some reason or popped up twice; instead, it was an important security update about Internet Explorer. It's good to know that in case something major pops up, M$ releases the update before the next scheduled patch Tuesday. Sadly, though, there aren't many patch Tuesday left for us... :'(

Speaking of Skype, the new version (8.37.76.26) now requires at least Android 6.0, which means that M$ dropped support for me on both my desktop (running XP) and my mobile (running Android 5.1.1). What a Christmas present, Microsoft... -.-

Leave it as it is, but keep in mind that both 7.36 and 7.38 use an old version of the protocol which won't be supported as soon as M$ pulls the trigger. Probably, the only difference between 7.36 and 7.38 it's the annoying support message (I wouldn't be surprised).