FranceBB

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

This is the nmap output from the Fedora host: This is the route on the host: but nothing changed. I'm now trying a different approach, which is routing all the traffic from wlp2s0 to tun0, but unfortunately, I don't know how to do that. I tried with: sudo ip route add 10.42.0.0/24 via 0.0.0.0 dev tun0 but nothing happened. sudo iptables -t nat -A POSTROUTING -s 10.42.0.29 -o tun0 -j MASQUERADE sudo iptables -t nat -A POSTROUTING -s 10.42.0.0 -o tun0 -j MASQUERADE sudo iptables -t nat -A POSTROUTING -s 10.42.0.1 -o tun0 -j MASQUERADE didn't work either. Routing wlp2s0 to the ip address of tun0 prevents devices connecting to the wifi to access internet: sudo iptables -t nat -A PREROUTING -i wlp2s0 -p tcp -j DNAT --to-destination 10.8.8.0 sudo iptables -t nat -A PREROUTING -i wlp2s0 -p udp -j DNAT --to-destination 10.8.8.0 Routing wlp2s0 to the ip address of my ethernet prevents devices connecting to the wifi to access internet: sudo iptables -t nat -A PREROUTING -i wlp2s0 -p tcp -j DNAT --to-destination 10.8.8.0 sudo iptables -t nat -A PREROUTING -i wlp2s0 -p udp -j DNAT --to-destination 10.8.8.0 Routing wlp2s0 to the external ip address of my VPN prevents devices connecting to the wifi to access internet: sudo iptables -t nat -A PREROUTING -i wlp2s0 -p udp -j DNAT --to-destination 192.168.0.0 sudo iptables -t nat -A PREROUTING -i wlp2s0 -p tcp -j DNAT --to-destination 192.168.0.0 In other words, it's a mess.

Yep, Discord uses Electron and Electron doesn't work on XP. Besides, the web version doesn't work neither on Chrome 49 nor on Chromium 54 as the page doesn't load and it's just blank. On Firefox 59.9 ESR Discord *does* load, however it's buggy. I think @Dibya will be pleased to know that another app uses Electron. (He hates it xD).

Exactly. @someguy25 I've been using Linux for years and I can say that some things just don't work. I'm using Fedora on my laptop 'cause it came with Windows 10 out of the box, I gave it a shot and I didn't like it. I've been using Arch Linux since 2005 as dual boot on my desktop, but when I purchased my new laptop in 2016 I had to install Fedora 'cause it needed the very latest kernel and drivers to work. Unfortunately, because Fedora receives constant updates and it's a sort of "preview/unofficial beta" of RHEL, things can break... and pretty badly. I had configuration files corrupted during the upgrade process due to a bug in dnf, I had programmes not running on Wayland, but running in xorg, I've been dealing with tearing due to a different refresh rate of the monitor and GPU, I had my computer failing to boot due to bbswitch waiting for the GPU to announce its state without ever getting a response, I had several issues with NVIDIA drivers including the official ones, negativo's modded ones, nouveau, implementations like bumblebee and optimus never really worked, and many many others issues. I mean, Linux is great, it's open source and there are many different distributions, but you have to accept that things might not work and there's nothing you can do about it, other than spending time reporting it with the automatic bug reporter, attach the logs, and either wait for someone to care and fix it, or dig deep in the programme/component/dependency affected, try to fix it yourself and then eventually commit the change. (And keep in mind that nowadays, Linux is much more user friendly than it used to be many years ago).

Done. Thanks! Now it really looks legit, including the logon and shutdown messages.

Creating a new user didn't solve the problem as the new user still had menus in Italian. Out of curiosity, I opened up the register and I found a few another strings that needed to be changed: 1) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NIs\ There was a REG_SZ string called "0410" and I renamed it "0409". 2) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NIs\MUILanguages There was a REG_SZ string called "0410" and set to 1; I simply renamed it "0409". After rebooting, now many menus are in English even for my "old" account and for every new account as well. I hope it will be useful for other people in the future. p.s too bad the Recycle Bin will be "Cestino" forever xD

Hi, I have Fedora 29 and a few connections listed below: NAME UUID TYPE DEVICE > Hotspot ad2a19b6-6347-4e48-a6f7-1446d4a96d0d wifi wlp2s0 > pan1 0611ae9d-dd40-49b6-91bb-16d95ff21624 bridge pan1 > tun0 447c77d6-005a-422f-b93a-ac4e40474460 tun tun0 > uk656.nordvpn.com.udp f68bfe83-7c23-4bff-9bd8-996510849ea4 vpn enp0s20f> virbr0 6db6a458-7832-414c-9e6f-917a3e7e494b bridge virbr0 > Wired connection 1 9a79441a-2644-3cc9-9cb0-0376935fc0e7 ethernet enp0s20f As you can see, "enp0s20f" is the ethernet, then there's my VPN and finally there's "wlp2s0" which is my Wi-Fi hotspot. The idea is to basically get internet from my router, route the traffic throught the VPN and then send out a Wi-Fi hostpot signal to allow devices to connect using my VPN. So far so good. The problem is that I had to implement a kill switch. To do so, I used UFW, by blocking all the incoming and outgoing connections except the ones from/to the VPN servers (I specified their ip). To Action From -- ------ ---- SSH ALLOW Anywhere 224.0.0.251 mDNS ALLOW Anywhere Anywhere on wlp2s0 DENY Anywhere SSH (v6) ALLOW Anywhere (v6) ff02::fb mDNS ALLOW Anywhere (v6) Anywhere (v6) on wlp2s0 DENY Anywhere (v6) 89.238.183.8 ALLOW OUT Anywhere 81.92.202.17 ALLOW OUT Anywhere 89.238.142.133 ALLOW OUT Anywhere Anywhere ALLOW OUT Anywhere on tun0 81.92.203.47 ALLOW OUT Anywhere 185.169.255.20 ALLOW OUT Anywhere 185.195.202.28 ALLOW OUT Anywhere 195.12.49.141 ALLOW OUT Anywhere 185.195.202.20 ALLOW OUT Anywhere 185.195.202.22 ALLOW OUT Anywhere 23.226.129.171 ALLOW OUT Anywhere 104.222.153.56 ALLOW OUT Anywhere 185.217.69.182 ALLOW OUT Anywhere 194.242.11.142 ALLOW OUT Anywhere 82.102.22.91 ALLOW OUT Anywhere Anywhere DENY OUT Anywhere on wlp2s0 195.12.49.141 ALLOW OUT Anywhere on wlp2s0 Anywhere (v6) ALLOW OUT Anywhere (v6) on tun0 Anywhere (v6) DENY OUT Anywhere (v6) on wlp2s0 It works like a charm on my computer, but devices on my Wi-Fi Hotspot are not affected by any rule set on UFW. I found another person with the same issue (but with Ubuntu instead of Fedora): https://askubuntu.com/questions/1032183/ufw-doesnt-work-with-hotspot Why is that? Thank you in advance, Frank.

Yep, I switched to the Web version long time ago, but it doesn't support calls on XP (I use my phone whenever I have to call someone). For the records, I tried the new version of Skype web on Chromium 54 and it works on XP, even though the new UI has a few... uhm... "glitches" (but I can live with that) https://preview.web.skype.com/ @someguy25 The reason why there aren't alternative clients to Skype (or backported ones) is that Skype doesn't use the Skypekit anymore, as they removed the support to Skypekit in 2013/2014 (if I recall correctly). Killing the Skypekit meant that the only official working client would have been the official Skype app and programme, which basically meant more cash thanks to the ads for them. Unfortunately, this played against us, 'cause I tried to use the old Skypekit I had saved, but it refuses the connection. With a few mods I managed to get it working, but only for normal-chats, then Microsoft changed the protocol again and moved everything to the cloud (messages are now stored on MS servers on the cloud), therefore the old modded Skypekit didn't work at all. (I've been over this years ago in 2014 'cause I was using Trillian instead of the official Skype and Trillian was indeed based on the Skypekit). In other words, you won't find a backported version of Skype easily anytime soon (definitely not by me). If someone else wants to give a shot, I can only say "fill your boots" and "good luck".

Not this time Dibya... I'm generally angry when developers stop supporting XP, but not in this case. In all fairness to them, they'll stop supporting XP on May 14th 2019, which means 1 month and 5 days after the end of Extended Support (April 9th, 2019). (for those who were wondering: I'm not a gamer, I've never been such and I stopped playing "games" long time ago).