Leaderboard

He hasn't posted here since last summer, although he is still a member. You could try sending a PM, but it would be much better to ask about your issue on the Supermium GitHub pages.

Friend, in as much as I want to help you, I can't. Never encountered such problems with Vista. I don't have 8.1, and here we have only one true 8.1 fan @Jaguarek62, as far as I know. Did you try different drivers?

Didn't work for me, so I used the Gigabyte tool I mentioned earlier + the official Intel drivers, why would want to use un-official, if there we have Intel certified drivers? Are they faster? I'm just curious, nothing more. I'm trying to broaden my horizons.

At the moment, I have reverted to the last officially compatible version 1.46. But I will test the 1.56 version again. Thanks for the hint! @feodor2 I moved to the most recent, final version of uBlock Origin which is 1.62 at the moment. The logger works fine in multi-process mode but in single-process mode, the logger popup window is very unstable. Some extensions, scripts and whatever else interfere considerably with the loading and display of the logger popup. It often remains empty. Resizing the logger window helps in some cases. I investigated this further and found that changing the advanced setting loggerPopupType from popup to normal may be a solution. In this case, the logger is opened in a normal window in which it loads fine as far as I could see until now. At least, on my computer with its current configuration. I'll keep an eye on that. P.S.: @feodor2 Now, I have realised what you meant by using the context menu. I have never opened the logger interface via its icon context menu before. Indeed, this also works in both process modes to properly open the logger in a tab or window. However, changing the advanced setting loggerPopupType from popup to normal is of interest for those who prefer only one normal left-click on the logger icon as usual.

I already wrote about this general.config.sandbox_enabled preference in terms of the Nuchi-Sporif script loading method and other ones:

@BlakByte With 24H2 there is known similar issue (everything but mouse frozen) which is result of run as administrator (and UAC prompt) or run as a different user, not exclusively related to Microsoft Terminal been launched. This is almost guaranteed to cause the same result where only hard reboot fixes it. I am also running SAB, but verified that SAB is not related, at least to this specific issue. https://github.com/microsoft/terminal/issues/18105

None, those can't be trusted in testing your hardware. I had several cases where my RAM passed all tests with flying colours, running from there, then failed with booting Windows.

Why you use flash drive to install windows? HP 600 should have a blu-ray optical drive. Why not install using DVD disc and optical drive? Did your XP ISO have AHCI drivers built-in with NLite? Or change AHCI mode to IDE in BIOS. Maybe just change HDD and try again? That's all ideas so far.

... In addition to what already posted by Dave , the "official" contact channels are to be found at: https://www.win32subsystem.live/supermium/support/ Kindest regards.

It depends if there is a wimlib_WIMHOST_error.log than 47 is one of the wimlib error codes else it would be a System Error Codes.

There is test version: http://sweetlow.orgfree.com/download/usbehci.zip with BIOS EHCI Hand On, but it does not work on all tested systems. With high probability modern BIOSes just omit this function as NT-like OSes (and even ME) just do not have such thing as exit to real mode. Or some condition should met before transition of ownership for USB controller from OS to BIOS but there is nothing in standard about this.

Firefox has a sandbox even for the outdated, initially unsafe and poorly implemented garbage like Flash. Flash was supported with XP for like quarter of a century, what Windows 10 are you talking about? "Firefox has a sandbox for some plugins like Flash, and it has a sandbox for media decoding plugins and DRM plugins. These are all enabled by default." It's from a decade old article. https://support.mozilla.org/en-US/questions/1111998

Yes, I understand about one "not designed for single process". And what about the other 99.999999% of users that have at least a dual Pentium?

You want to say, in the original Firedox 68, sandbox doesn't work, too?

Today, I created a subroutine to catch errors ,for example a TypeError, caused by the document.getElementById() or document.querySelector() commands when a page is loading too slowly. I use these error messages to check as long as a successful access to an element is granted and then to immediately execute the desired commands. This avoids unnecessary, static setTimeout commands and error messages in the Browser Console.. Works like a charm. And I'm not in the mood to use observers everywhere.

I thought the general.config.sandbox_enabled preference is the one to be enabled if the user wants to use the sandbox feature.

It's what agendalists stuff in your brain, it's not your problem, ignore everything what is not your problem. They off-load their work on civilian population. EDIT. You need to fight the depression with fun, we talked about it.

Keeping single-process mode is really a good idea and very important for those running Windows XP on old, weak computers. Actually, this mode works much better in Mypal 68.14.7b than in the previous releases. I've already mentally and emotionally prepared myself for the next compatibility breakages you'll soon be unleashing. I am really curious to see what will no longer work in the next version as it did in Mypal 68.14.5b. In the meantime, I have written a whole series of UC.JS scripts to be on the safe side if a lot of my older stuff do not work anymore. Hope the Custom Buttons extension will still work in your next Mypal 68 release as it should actually be able to run in newer Firefox versions up to at least 136 as well. And if it works there, it should also be possible in newer Mypal 68 versions with a much lower JavaScript level.

@feodor2 When creating UC.JS scripts, I noticed that some Vanilla JavaScript commands behave differently in single-process mode compared to multi-process mode. When starting the browser, loading new tabs or windows, accessing elements via document.getElementById() and especially via document.querySelector() needs much more time in multi-process mode than in single-process mode. Is there any explanation for this? Is this by default or rather a Mypal 68 specific behaviour? When, for example, starting the browser with the about:addons page, it takes nearly 8 seconds after DOM is loaded to be able to access an element in multi-process mode via document.querySelector() . In single-process mode, it can be accessed directly. This is very strange and does not make the multi-process mode particularly attractive.

They also say it could be done with another method with Samsung tool. https://www.techpowerup.com/forums/threads/gigabyte-windows-7-usb-installation-tool.249384/

Saxon is right, you didn't give any links to the tool itself, but probably because they removed it, here it is. https://www.mediafire.com/file/b4vxpuw136x6qsf/WindowsImageTool.7z/file

Supermium 126.0.6478.261 R7 is now out, apparently the last 126 version. A 132 version is due in February. I don't think I will bother to update again until the 132 version is released.

Yes, they have such an extension. I downloaded it from the (also crappy) Discord, which was rather a torture , and installed it in New Moon 28. It works in the same way the script already does but the search box issue of course still exists.

The original YouTube interface is simply crap. YouTube is a perfect example how to continuously update an awesome website to an awful one without considering the users. I've actually hated YouTube for years , but the Project VORAPIS with its old, classic frontend has brought the joy of YouTube back to me. That's the way it was and the way I like. But if VORAPIS V3 doesn't work for you properly for whatever reason, you can also use the extension uTube for watching YouTube videos in UXP browsers in a very resource-saving way. I additionally use uTube in New Moon 28 and Serpent 52. The install.rdf file has to be edited to make uTube compatible with NM and SP, though.

Yes, I also observed this issue , and no, it is not related to all UXP browsers . I have already installed VORAPIS V3 on Mypal 68, New Moon 28 and Serpent 52. The issue that the video player resets after some time and then all higher resolutions disappear is only related to New Moon 28 (and presumably also to Pale Moon). In Serpent 52, the VORAPIS V3 script works out of the box without this issue. The reason for this issue is the VORAPIS script Vorapis.user.js itself, currently in the version 0.8.9.25, (and also some previous scripts as for example the version 0.8.6.16) which doesn't work properly in New Moon 28. I fixed this issue by using the VORAPIS launcher script patcher.user.js in the version 1.0.8.8 extracted from the webextension "V3 - Get Old YouTube Layout (Launcher)". They show a messsge on the YouTube site that it is not the full version but it is enough for me. Searching and playing videos is working as it should. I removed the blue message box from the frontend with uBO. The Project VORAPIS script has been updated today to the version 0.8.10.26. The issue that the video player resets after some time and then all higher resolutions disappear in New Moon 28 seems to have been fixed.