Content Type
Profiles
Forums
Events
Everything posted by UCyborg
-
My Browser Builds (Part 4)
UCyborg replied to roytam1's topic in Browsers working on Older NT-Family OSes
It's not technically corrupt (well it could be said from the older version perspective), sometimes you just have to move/migrate things around, rewrite some data to improve something and the old version obviously doesn't understand these changes. It's a one-way thing and the only guaranteed way back is with a backup. This is actually tweakable. There are registry settings specifying how exactly should the associated program be invoked, so you can put whatever arguments you need there. Does shell->open->command ring any bells? -
Note that multi-process prevents operation of certain extensions. I don't know what kind of stability issues people have, but at least my experience with official 32-bit Pale Moon on Windows 10, it may hang permanently after consuming certain amount of RAM, presumably due to memory leaks and fragmentation. On 64-bit OS at least, hanging due to leaks shouldn't occur with 64-bit browser due to much larger address space. At least it never happened on my work laptop where I got more RAM to spare and just run 64-bit build.
-
The personal perspectives will differ. I'm not prone to optimism bias. Either way, 1h into new year here. It's peaceful again, the banging has stopped.
-
I didn't choose to have to deal with this crap. My remaining parent got ill for over the week from the shock after receiving the letter from the lawyer from the "other side". Imagine the dread of taking care of someone that was completely helpless, then that person dying and then receiving such letter. This is not how grieving process should like and it's not something I can ignore, it fell upon me to do something. I didn't choose to come into the world ruled by greed and corruption (or being born in general). But here I am and quitting ain't easy. So I improvise. Day by day. I try to forget about this thing, but got reminded with a recent mail from our lawyer letting us know what "they" were snooping at.
-
One of my parents passed away this year and that person's death opened a whole can of worms. That person had another kid with another person long time ago and that kid is a real piece of work. The kid went crying to the lawyer and attacked us about heritage, despite already getting a very valuable possession long ago from the deceased parent. On top of that, the kid didn't give the damn about the sick parent, whose sickness eventually lead to demise and who couldn't take take care of oneself on its own in the last months of their life. So it's gonna cut into savings, it already has, lawyers are expensive, but will try to salvage as much as possible. I'm not too hopeful as the laws in this stinkhole are retarded. Who cares if you were actually there for the person, but someone who didn't lift the finger can get money just like that. And we're talking of someone driven by nothing but greed. We didn't really have any connections with those people, my parent split with that person and started again. I could tell from once in a bluemoon visits from the "other side" they can wipe their asses with money. My parents were a strange couple TBH. The deceased one considered it all agreed upon (regarding that s*** that's happening now). But they didn't think of such possibility.
-
So much noise from new year celebrations, ugh. What is there to celebrate anyway? Every year is worse than the previous one. Not looking forward to 2023.
-
It has to support rebasing due to Windows executable design, which is not position-independent. ASLR on Vista+ is just implemented in a way that when the DLL is first used (same should apply for EXEs), it will reuse the same random address in subsequent processes. Though looking at my Win10, this doesn't always seem to be the case, choosing two processes for comparison, one native executable and one .NET executable, the .NET one had differing addresses in two instances of the process. DLLs had to have relocation tables in any case due to possibility of conflicts, old EXEs did not have them, they're always first inside the address, but since ASLR is the thing, EXEs have the relocation table well so they can be relocated freely inside address space by the ASLR feature. Edit: Perhaps .NET executables/images are different, but native .NET images might behave the same as normal native images, not sure.
-
Well, I meant that the OS will rebase in memory/pagefile when it's loaded if there's a conflict, that causing BSODs is really strange. I tried WiseVector StopX really quick in a VM, couldn't install in that old messy XP x86 SP3 VM, the installer crashed, but I could load it on XP x64. Seems to put quite a strain on the CPU when Chrome does something, though I couldn't crash the system. Maybe I'll try again at some point with fresh XP SP3.
-
Are you sure? Mozilla based browsers, which you use as well, have a bunch of DLLs with preferred base address 0x10000000. BSODs come from something going wrong in kernel space, although whether something in user space triggered that something is another question. Kinda doubt runtime rebasing is the main culprit, perhaps it just exposes a bigger problem.
-
Off-topic, but you can actually use Dropbox to share these things (rhetoric question)? I used to share something using it, but after some time, my link errored that the account's public links are generating too much traffic. I wonder if the limits these days are the same than they were few years back. On-topic, is there a changelog for official builds? What's the difference between 1030 and 2022 and why would one be slower than the other, both being Chrome 86?
-
Interesting piece of malware: Report on VirusTotal This guy ran it under built-in Administrator account. I tried it in a virtual machine in XP under the restricted user account in Users group, it failed to do much, it errored out that it's corrupted. Buggy virus!
-
My Browser Builds (Part 4)
UCyborg replied to roytam1's topic in Browsers working on Older NT-Family OSes
Same in official Pale Moon, works in SeaMonkey. -
I did notice it months ago, just thought it was funny compared to 64-bit Edge on my Win10 install, brushed it off to ancient OS + Made in China browser combo and didn't think about it further. I'm not sure there's a good reason to have two versions, I don't think rebased version would offer any disadvantages on NT 6.0+ compared to non-rebased. And for those opposed to using software that caters to the lowest common denominator on the API level on newer OS, especially NT 6.1+, I suppose this browser wouldn't do anyway if they find something else that suits their needs.
-
Alright, tested the load time of browser again after Windows startup and after the other startup programs have loaded. All on already good warmed up PC, well, as warm as it can get when the ambient temperature is about 15 degrees Celsius or so does my thermometer say. I can confirm approximate 4 to 5 seconds delay with rebased DLL here after 3 tries. Very curious. Now who can explain that? I save load of RAM with rebased DLL, if I take 14 same tabs, we're talking total RAM consumption of the entire system of 1,4 GB vs 3 GB. Chrome loves multiplying its core process you know, it's not just the first 800 MB and some, assuming you open a bunch of tabs. Funny you mention walking to the other higher end PC @NotHereToPlayGames, what about boot time of that PC or are we talking about PC that's already on? BTW, I got chrome.dll at 0x3E1C0000 now. LOL, this whole thing feels like DOS all over again.
-
Only those that have DLLs loaded in other applications. It might be unrealistic to be able to make public release with the "perfect" alignment, I think avoiding the popular 0x10000000 is good enough start, you basically want to avoid that huge DLL from being rebased by the OS, it has to be first to occupy its space. If you use some debugger, you could pause it at the point chrome.dll is loaded and see what's free. With public releases of software in general, it's probably unavoidable that a DLL there or there is rebased, but the issue is smaller with smaller DLLs. AFAIK GCC for Windows uses some own logic to choose address for DLL when building, eg. compare DLLs of T-Clock Redux, one version with built GCC, another with Visual C++, latter has MSVC default address while the other has it in the high range 0x60000000. NVIDIA's driver DLLs (at least I checked OpenGL one) for instance also has a high address in 0x60000000 range, but I doubt NVIDIA used libre compiler, so must have chosen their own / put it with others through REBASE.EXE with high starting address or something, who knows, not much about rebasing written or I haven't searched thoroughly enough. Mentioning because I rebased DLLs of the other browser and forgot about WebGL initially, which loaded OpenGL driver, so my first chosen address ended up in a conflict with the driver DLL, which had to be relocated. I actually went with a bit lower address for chrome.dll, I can post it when I get home. There might be something about loading delay with high address and big DLL here too, not sure, my XP is more sluggish on some days at startup than others. Since YouTube often comes up in these browser discussions, neither the new test version of ImprovedTube extension nor current version of Enhancer for YouTube are compatible. Funny thing about ImprovedTube, not sure it's legacy OS thing / something missing in them (who knows what...), but even the last working version has an issue that buttons labels in main menu are missing and the picture buttons are bigger because of it.
-
If you uncheck Hide free regions, it shows free spots and I noticed on my system there was cca. 17 MB free region between rebased chrome.dll at 0x62A00000 and wow64.dll. Though I didn't keep the browser open long enough to notice rsaenh.dll loading a bit later, which has preferred base address set to 0x68000000 (you can check that with Tools->Inspect executable file...BTW, it's possible that thing will erroneously show 64-bit hex number on XP x64, despite looking at 32-bit DLL, if I'm not mistaken, if you cut it in half and look at the first part, that should be correct), which then had to be relocated since part of its space was occupied by huge chrome.dll, which wouldn't have to be otherwise. Your screenshot shows chrome.dll made it to default 0x10000000, so the issue with big consumption doesn't occur. If you go really nitpicking, I think you'd ideally want DLLs crammed somewhere together to reduce address space fragmentation, in the 90s, you could have those DLLs all over the place at higher addresses and it wouldn't be a problem since address space (4GB - 2 GB usable) was huge compared against available RAM capacities, but today, you can easily consume it all, but again, in this case we're dealing with Chromium that splits itself in multiple-processes...does single Chromium process ever start to consume as much in practice that it would become the problem? I know it looks weird when you look at it at first, but basically every 32-bit process has 4 GB virtual address space to play with where its data in RAM are mapped, executables not marked with Large Address Flag are capped at 2 GB, though practically utilizable numbers are smaller. If I remember correctly, these things are explained in Windows Internals, one cool and long book about Windows technicalities. Oh, the REBASE.EXE I mentioned, it's the tool that was bundled with older Microsoft Visual C++ IDE (Integrated Development Environment), maybe also older Microsoft Visual Studios (individual suites for each language (C++, Visual Basic...) were later combined into one Visual Studio, well, the tools are still separate, there's just one big program from where you open project files and edit code).
-
Do as you want. I've rebased chrome.dll with REBASE.EXE to be closer to wow64.dll on 64-bit XP, 17 MB gap before it was reduced to somewhere below 1 MB, so went from 0x62A00000 to 0x63A00000. Good enough for me and those occasional boots to XP, no side effects. No comment on 14s delay, first time I hear of it, maybe rebase to the address the OS chooses itself when it has to relocate the DLL from default 0x10000000?
-
See if --disable-windows10-custom-titlebar changes it.
-
360 Extreme Explorer Modified Version
UCyborg replied to Humming Owl's topic in Browsers working on Older NT-Family OSes
I guess what I was getting at is how much work is there in the background for providers to set things up. Because maybe where PlayReady is supported, it'll last longer before it stops working on Windows 7. I also saw those functions you mention and they're definitely not in vanilla kernel32.dll of Vista SP2. So Widevine can't work on vanilla Vista since they're hard dependencies and the lack of those functions would result in failure loading Widevine DLL.- 2,340 replies
-
2
-
360 Extreme Explorer Modified Version
UCyborg replied to Humming Owl's topic in Browsers working on Older NT-Family OSes
Seems videos originate from YouTube, at least that's what it seemed after checking few. You just reminded me of my previous computer, it was all sluggish 'til it warmed up. Seems to be Chromium 75 based indeed. I guess update URL was cleared from the binaries, so browser doesn't pick the current version, but latest Widevine from Chrome 108 works with it on recent enough OS. I wonder if Netflix and such require Widevine specifically. Would PlayReady CDM also work or does it have to be supported specifically (from little searching it could be the case)? Because on that test site, PlayReady from Edge 94 still works.- 2,340 replies
-
1
-
360 Extreme Explorer Modified Version
UCyborg replied to Humming Owl's topic in Browsers working on Older NT-Family OSes
Plus Widevine is one of those ugly Google things built with an expiration date, sooner or later it stops working and you need a new version. Look on the bright side, that way, you are liberated from those POS streaming services.- 2,340 replies
-
1
-
360 Extreme Explorer Modified Version
UCyborg replied to Humming Owl's topic in Browsers working on Older NT-Family OSes
Installed software can influence whether chrome.dll will make it to 0x10000000 address or not, eg. I have number of programs which DLLs load in most processes - Actual Window Manager, HardLink Shell Extension, VirtualMIDISynth, Office 2010 - all of these have DLLs that compete for 0x10000000 spot.- 2,340 replies
-
1
-
My Browser Builds (Part 4)
UCyborg replied to roytam1's topic in Browsers working on Older NT-Family OSes
Newer Nextcloud versions using Unicode property escapes work with the new UXP additions . @roytam1 Please consider looking into rebasing your browsers' DLLs. XP and older systems cannot optimize memory usage when it has to relocate DLLs in memory like ASLR supporting OS do (I haven't checked if the memory usage woud also creep up with ASLR off on Vista+, so with dynamic base flag turned off in executables and DLLs and using default base address). This will save memory, especially with multiple instances of the browser process. https://msfn.org/board/topic/184135-arcticfoxienotheretoplaygames-360chrome-v135-build-2022/?do=findComment&comment=1232976 You could try LiBase utility for the hint what addresses to use, but then use linker's /BASE argument to specify it for each DLL when they're built. Check if that argument doesn't invalidate default /DYNAMICBASE setting, which sets the flag to enable ASLR on Vista, which I think is OK to keep. If linker clears it for some reason from resulting executable, then I guess there's a way to configure somewhere in the build environment to run LiBase as post-link step on the built DLLs or have the BAT or similar to run it manually at the end.