Leaderboard

3.9 beta 2 https://startisback.com/StartAllBack_setup.exe New taskbar perk: Slightly larger bloated swollen plump classic taskbar to match Win11 aesthetic (or adjust vertical spacing or make taskbar float), with optional size bulk heft / padding pillow buffer / margins floating aura option. Other notable changes:

Does Supermium have built-in certificates? Yeah, the certificate aspect of XP has become obsolete. I used to use them for streaming media players like SMPlayer. But those stopped being able to open most media for various reasons. Facebook has started showing me a message about New Moon being obsolete. It can be dismissed. https://i.imgur.com/jQxMpmt.png

Or maybe it only happens if you're faster than the browser can process. Does this site work for anyone? https://europe.beyerdynamic.com/ No reason to bother with that unless you use Chromium AFAIK. And even then it's not a 100% thing, there are a bunch of certificates XP doesn't understand anyway and validation fails.

Here are several that I have used in the past. Fast tests that don't drive my impatience through the roof - https://mozilla.github.io/krakenbenchmark.mozilla.org/kraken-1.1/driver.html http://proofcafe.org/jsx-bench/js/sunspider-1.0/driver.html https://browserbench.org/Speedometer2.1/ Slow tests that I do not have the patience to run very often - https://web.basemark.com/ https://browserbench.org/JetStream/ https://browserbench.org/MotionMark1.3.1/

@Dietmar A few edits had to be made. Used -DWIN2K_COMPAT_SLIST_USAGE=1 switch when compiling. Stubbed HeadlessDispatch. Had acpi driver do ExInterlockedCompareExchange64 internally. Commented out HaliIsVectorValid where present. Needed to pass procinit explicitly to HalAcpiMachineStateInit in NotifyHalWithMachineStates.

Edited 2 hours ago by seven4ever But @feodor2 didn't say that. It is just your request. Your post is a bit misleading due to your wrong quotation. Anyway! You can vote for a new SSE version here: https://github.com/Feodor2/Mypal68/issues/164

As @feodor2 already tested this extension in Mypal 68, I think it costs only seconds to test it in a more recent Firefox version. I assume that a developer also has access to more modern Windows versions. But if you want to test this extension, do it and report here your results. I'm not going to do that because I don't care about modern browsers. I definitely don't develop anything for these browsers.

Last time, you stated that you do not surf anymore under Windows XP. You have to stand by your statements at some point. You've given up Windows XP and you've said so everywhere. You only need Windows XP for your oldtimers, but not for everyday surfing. Somehow, you're just a flag in the wind. Like this today and like this tomorrow.

And please, speak only for yourself! You don't know what others think or want. This is a very bad habit. And since you don't actually have any use for this browser, it's not particularly relevant what you would like to see in the development of this browser. Sorry, but that is the truth. But if you want to keep shooting at me, then don't force yourself. But, as is often the case with you, it has absolutely nothing to do with the real issue.

Why should I test things I hate and which are already reported elsewhere to be working? So, there is no contradiction at all and nothing is misleading. This thread is not about modern Firefox browsers. So, I fear you are somehow confused and misled as you didn't really follow this thread and my thread about Mypal 68 in its entirety. And BTW, you did nothing meaningful here. One doesn't have to put his two cents in everywhere. Especially if one doesn't need Mypal 68 at all. And as you already stated, you are a Windows 10 user at home. This browser is not meant to be used under this OS. And you do not surf anymore under Windows XP. So, you have no real use for this browser.

As far as I know and have read about this extension, it should work in more or most recent Firefox versions. However, since I hate all recent releases of Firefox and am a die-hard Windows XP user, I did not explicitly test the most recent Custom Buttons extension in more recent Firefox releases. I use the newer, crappy browsers as they are and only when I have to. I know. You are the creator of Mypal 68, and you have to decide what will be changed and updated in your browser. I am just a creator of custom buttons, CSS styles and scripts, a code modifier who tries to fix already existing code to make it working again. Nevertheless, I developed a lot even for Mypal 68. Anyway! Do what you have to do but please keep in mind that compatibility is a valuable asset contrary to what Mozilla is doing . To preserve the possibility to run some older stuff in more recent versions of Mypal 68 would be great, though. But if it is not possible to preserve certain, old stuff due to important and necessary changes, then, for better or worse, that's what will happen. Don't worry about my beloved custom buttons! I have already started to port my custom buttons into UC.JS scripts. Unfortunately, I have to change a lot, and the JavaScript syntax is different, but I have steadily expanded my JavaScript and CSS skills. But one thing is crystal clear. The Custom Buttons extension is simply great, incomparable and in all its facets irreplaceable. So, try to keep the compatibility with the Custom Buttons extension as long as possible! BTW, I have already fixed all issues by myself in Mypal 68.14.5b regarding the broken UC.JS scripts and CSS styles. Except the Custom Buttons extension, of course. For the UserCSSLoader, I created a complete, new CSS stylesheet. But it was much more complicated to do as before which means I don't like the new CSS. The old one was much easier and more effective. I don't understand why the more recent has to be the more complicated and restricted in these days. And I replaced the Extension Options Menu script by a more recent one. Unfortunately, I could no longer save my version.uc.js script, and therefore I had to replace it with something similar.

I don't think that 99% users won't bother with "editor path" and consider it as broken. The popup clearly tells the user to set a path to their favoured editor via a preference called view_source.editor.path in about:config for editing CSS files by this script. As it is totally self-explanatory, I have not mentioned this. If a path to your favoured file manager was set in line 46 of this script and a path to your favoured editor via view_source.editor.path, then all menu items will definitely work. And you doesn't seem to have understood what the "Import styles" entry is intended for. When clicking this entry, then all CSS styles will be loaded again on the fly. In the case that all styles have already been loaded, then clicking onto it will logically do nothing. But you can check very easily whether this feature is working or not. Copy a new style in the form of a CSS file into the CSS folder while the browser is running. It is not yet loaded. Now click on "Import styles", and the stylesheet is loaded immediately, i.e. without restarting the browser.

It was an obvious fake right from the start. Too obvious. I wrote about it in the beginning. I don't know why people spent their time. May I kindly request @Dave-Hto take action against the user named @TheLeftOldComputer under the section 4.e - vapourware. Edit: I wrote here. https://msfn.org/board/topic/186356-just-bored-what-software-should-i-create/#findComment-1269908

Great! Mypal 68.14.6a again with browser.xul. But who or what is xioxui? Maybe, you meant xiaoxiaoflood? Anyway! Development must go on but keeping compatibility as far as possible would be really great. That's why I don't like Mozilla's way of development. New releases, and compatibility breaks without end.

I'm glad to hear it. 1. What search are you talking about? 2. Sorry but that is not true. The UserCSSLoader script is fully working in Mypal 68.14.4b. Here is a short demo: The "Import styles"is only necessary if new styles are added or some styles have been edited. When starting the browser, all styles are automatically loaded by this script. And what do you want to open? The CSS folder? A stylesheet in an editor? The userchrome.css file? Please describe it a bit more detailed! I can't do anything with statements like that. In any case, if all is configured as I described in my instructions very detailed inside the uploaded archive, then all features of the UserCSSLoader script are definitely working. The reported issue was its CSS stylesheet which does not work in Mypal 68.14.5b only. 3. Sorry but that is not true, either. The Custom Buttons extension works fine in Mypal 68.14.4b. At the moment, I have installed 11 custom buttons in this browser. Here is a short demo: For installing a custom button, you click the "Open file" dialogue from the browser main menu, go to the Restart & Purge v2.0 10-12-24 003806.htm file I uploaded for you and click onto it. Everything else goes without saying. If you want to see my most recent Process Mode Toggler custom button in action in Mypal 68.14.4b, then have a look at here: https://msfn.org/board/topic/183495-mypal-68/?do=findComment&comment=1275154

I think it is well known by now that I am a fan of custom buttons. The last months, I created a couple of them for the UXP browsers as well for Mypal 68. Here is one of my latest creations:

Doesn't this require an Intel third-party (ie, non-OS) utility/driver to be installed? If this came pre-installed, don't you only have yourself to blame if you didn't remove/disable? If not pre-installed but you installed this, don't you only have yourself to blame? If you allowed Windows Update to install this, don't you only have yourself to blame?

New version! No tally yet, but a better output: If no command-line switches are given, only the non-matching checsums files are listed. For the various alternatives use /? or -?. Please test. VRFYPE2.7z

When other approaches leave behind files of unknown integrity, calculate their MD5 and search the web for this. In most cases, the MD5 of executable files including DLL's will be recorded somewhere on the 'net, either from some site offering them for download, or some site that has performed a scan for malware on them. If the MD5 shows up, either someone has the exact same corrupt file (extremely unlikely) or it's good. Joe.

Well... it's my understanding you'd like to be able to check the integrity of every file in a CD/DVD or a CD/DVD image. I have no solution for that, sorry! However, as your initial post mentions specifically DLLs, I do have a partial solution for that, that may be of interest. Let's see its limitations: Not all files are executables, and for non-executables this won't work. Not all executables are PE files (i.e.: files in the Portable Executable format), and for non-PE files this won't work. Not all PE files are checksummed (i.e.: there are PE files with the header checksum set to zero, when the true checksum is not zero), and for non-checksummed PE files this won't work. But it works for all checksummed PE files! Now, the bad news is Win 9x/ME does not care about the checksum, so non-checksummed PE files are more common for those OSes than for those of the NT-family. In any case I've done some quick statistics using my C:\WINDOWS\SYSTEM folder as a reasonable enough sample to see how useful my method might be, and here're the results: Of 2232 files, 1574 (70% of the total files) are PE files. Of these: 1111 (70% of all PE files) have matching checksums, 451 (29% of all PE files) have zero checksum on the header and 12 (1% of all PE files) have wrong checksums (those are sloppily patched files, which checksum was not corrected, in this case). So, all in all, I was able to confirm that 49% of the total files are not corrupt, and had to investigate just 12 files... Seems good enough for me! The method consists in calculating de novo the true checksum of a PE file and comparing it to the checksum present in the Optional Header: when both match, the file can be assumed to be non-corrupted. The exceptions to this rule are some files that chip with a wrong checksum in the header... I found out that QuickTime.cpl is an example of such a file (three different versions of it straight from the distribution package came with wrong checksum set in the header). I've thrown a little console app together, which I call VRFYPE (attached to this post), to perform the checksum test on any number of files. It accepts "*.*" as a filespec and proceeds to check each of the files, ignoring the non-PE files, and providing three possible veredicts on the PE files it finds: checksums match, or do not match or the header checksum is zero, returning all info for any given file in a single line, together with the filename, so as to be convenient for filtering with FIND or related DOS filters. Please do test VRFYPE, and let me know of any bugs you find. VRFYPE.7z