Leaderboard

Thanks for your reply! I investigated the code of Custom Buttons more deeply, and you are right, the Custom Buttons extension solely relies on the platformVersion, Since you removed the XUL stuff, you logically can't keep the platformVersion at 68. But your new release Mypal 68.14.8b has become somehow versionless. It doesn't behave as a Firefox 68 and it doesn't behave as a Firefox 74. It's a bit lost. Your browser tells Custom Buttons that it is Firefox 74, but it is not. Today, for this purpose, I have made a proof and installed Firefox 74 Portable on a Windows 7 Professional 64-Bit notebook, injected the two files config-prefs.js and config.js, and installed the legacy Custom Buttons extension. As I have already predicted, Custom Buttons runs perfectly under Firefox 74. The code editor is fully functional. The legacy Custom Buttons extension has always been compatible with much newer Firefox versions and is constantly being developed further. Here are two screenshots to demonstrate what the issue is about: Custom Buttons' broken code editor in Mypal 68.14.8b: Custom Buttons' fully functional code editor in Firefox 74.0.1: As I already said, you must have removed something that Mozilla did not. And I suspect it has something to do with XBL. Certain functions for binding XML files are required by the Custom Buttons extension for the code editor, which you have probably removed. That's why I said your new release is somehow versionless. Neither fish nor fowl. Sorry for that! The conversion from XUL to XHTML is no problem as you can see. Anyway! I hope you won't behave worse than Mozilla did in the past, and I urgently hope you will be able to restore a general version compatibility. And it doesn't matter which Firefox version you raise the platformVersion to as nevertheless the Custom Buttons extension should work then.

Hello, I have release a new version of VT Hash Check 1.67 for XP that fix an esthetic/visual issue in the window of the settings. On the screenshots below, you can compare the difference. Before: On the left, the official/original release on Windows 10 On the center, my previous release on Windows 10 On the right, my previous release on Windows XP After: On the left, the official/original release on Windows 10 On the center, my new release on Windows 10 On the right, my new release on Windows XP The download link can be found in the first message of the topic. The mod is now complete. Regards

Usually it is enough if only RAMDRV4M.PDR is changed. But fix of problem with early unload was unusual as it required the change of Registry parameter for controller object...

The problem is completely solved. Everything turned out to be banally simple: to correctly update the product to a more recent version, it is not enough to replace "RAMDRV4M.PDR" in the "IOSUBSYS" folder. In order for the update to pass correctly, you first had to delete the controller in the device manager, as well as "RAMDRV4M.PDR", perform a reboot. Install the new version "cleanly". Only after doing all this together did the problem finally fully go away. Currently, performing a "hot reboot" (shift+restart) and the "exit Windows" procedure works correctly, without the need for user intervention. Thank you all.

So we may safely assume, no support for XP was ever inttended. Look here, https://aidanfinn.com/?p=13179 "Why Windows Server 2012 Hyper-V VHDX 4K Alignment Is So Important The current VHD driver assumes a physical sector size of 512 bytes and issues 512-byte I/Os, which makes it incompatible with these disks. As a result, the current VHD driver cannot open VHD files on physical 4 KB sector disks. Hyper-V makes it possible to store VHDs on 4 KB disks by implementing a software RMW algorithm in the VHD layer to convert the 512-byte access and update request to the VHD file to corresponding 4 KB accesses and updates."

AI answer.

@feodor2 Although Mozilla does and has done things to their Firefox browser for years that I personally think are terrible, certain features, even if they are considered deprecated and not secure, will be retained for compatibility reasons. That's something positive. On the subject of XBL and binding, what about the CSS property -moz-binding in your new release? This property is also used by Custom Buttons. For example, for the code editor in the file codeeditor-cbeditor.css: cbeditor { -moz-binding: url(chrome://custombuttons/content/cbeditor.xml#custombuttons-codeeditor); } #accelkey { -moz-binding: url(chrome://custombuttons/content/cbeditor.xml#accelkeytextboxbinding); } Can Mypal 68.14.8b even cope with this?

In comparison to Mypal 68.14.8b, I have executed the two JavaScript commands again in Mypal 68.14.7b: JavaScript commands: parseInt(Services.appinfo.platformVersion); Output: 68 parseInt(Services.appinfo.version); Output: 68 In any case, there is a clear version specification in the previous release.

I see, but how any of this is related to 1050 Ti and its inability to use drivers under XP?

My profile picture was also compressed to 3kb retroactively, despite it was added a long time ago and it was a normal size.

And that attempt was made using gtx1060, which is even older than 1050! XP drivers only exist up to 36x.xx , for 1050 you need 373.xx as the minimum. But it's only made for Vista and up (thanks to D.Draker). If you try, you will get BSOD.

First, 1050Ti is not supported even on Vista! But with @D.Draker ported driver it works with Vista. D.Draker never released 1050 driver for XP. No one did that. There was an attempt on youtube, but it failed miserably. No hardware acceleration worked because XP lacks directX 11, that's what I meant by properly.

We'd like to see a comparison, apart from the UI.

First of all, thanks for your feedback! System Error 3, also known as "The system cannot find the path specified," usually means the program can't locate the file or directory it's trying to access. Getting this error means you did unfortunately something wrong. Did you read my instructions carefully? After unpacking the archive file, you have to call first the ytBATCH.bat file located in the main programme folder. Then, you are asked to either setup ytBATCH for Windows XP to your programme folder of your system or to the location where you have unpacked the archive. All further processing is done by the script. Read this here: For a deeper, more technical explanation, read the post Setting up ytBATCH for Windows XP. And the scan result of the Window.exe file is as always a false positive. This file is used by me for sizing and positioning CMD windows and totally harmless. Long story short, delete your unpacked folder completely and do all once again! After unpacking again, solely and exclusively call up the file ytBATCH.bat file located in the main programme directory. And use ytBATCH for Windows XP 1.6! It is better than version 1.5 since it is more up to date.

FYI and for the cause research, if the programme has been called, and the window is not accessible, it appears the moment you open an Explorer window, very strange.

@genieautravail Your release VT Hash Check 1.67 for Windows XP is running fine here. But one thing is not working as described in the readme file. When clicking the main executable, the window is supposed to be opened to reach its settings. The programme opens, and I can see it in the task manager but its window is inaccessable. I can only reach the settings when performing a hash check. I don't think that was the intention. Or did I miss something? And BTW, the option SSL/TLS has of course to be enabled to establish a connection to VirusTotal.