All Activity

Well, more than at an OS level, I was thinking more about this being implemented at the router level. Currently there's NAT64 / DNS64 implemented in routers that is generally used to perform the opposite of what you wanna do (i.e allowing IPV6 clients to access public IPV4 only resources), however I wonder if it could technically be used to map public IPV6 addresses to internal private IPV4 addresses for older clients... I'm not a networking expert and even though I have an OpenWRT router, I don't really have a public IPV6 address from my ISP, so I can't really test / experiment with it as I'm behind CGNAT (IPV4), but if someone is more experienced and/or wants to test, please shout. This is definitely an interesting topic.

Isn't the minimum requirement chromium 138? https://www.securityweek.com/chrome-138-update-patches-zero-day-vulnerability/

brought back manifest v2 extension support. Cool! https://github.com/e3kskoy7wqk/Chromium-for-windows-7/releases/tag/140.0.7275.1

im not certain, it would requie to read out all the stuff that has been done related to this patches the /3GB is known to have some problems too, i dont know the problems with it j7n maybe has some knowledge here ? if its a problem with the /3GB switch there would be also the /USERVA switch to set a different value (between 2048 and 3072 (3 gb)) https://learn.microsoft.com/en-us/windows/win32/memory/4-gigabyte-tuning the one from dibya only use a small patch - maybe that would be worth a shot daniel k.´s patch use more of changes, maybe static offsets - that would be a reason why they dont work together also the method daniel k. described could trigger a crash not certain what "the russian patch" do to solve this problem is at the moment to much things around, i might can tell the norm´s, talks, idea´s a debug analize for example would take some time but if it comes to new work im busy at the moment sorry i also dont have the function test for dibya´s patch (aka if it passes the 4 gb limit) there should be someone to try these patches with the method j7n did to do so is simple just disabling the pagefile, then starting up app´s/executables that eat up more then 4 GB of ram if that is possible that patch is likely to work

Thank you so much, but I'm afraid that is pretty much all completely over my head! Do you know why the /3GB switch cannot be used with the RAM patch applied?

got a sn850x but it doesn't work on any m.2 slots in my B450 steel legend. with m.2 to PCIe x1 convertor it works, just too slow.

Unfortunately, after a few days of testing, there is still a problem with the lag on Haswell machine. I changed OS to my favorite - WinXP 64-bit - everything works ok and I have full access to RAM P.S. I wanted to add a RAM patch to my project on MDL - WinXP 32-bit on a modern PC (ISO boot.wim + install.wim) but since it works unstable, I will probably give up Maybe I will add as an alternative in the boot.ini and BCD file but not as default.

hmmm in the past we had often a discussion about "32 bit is the 4 gb limit" or = 32 wires 32 bits can form 2^32 bits therefore 4´294´967´296 what represents 4 GB the problem with that is that even in 8 or 16 bit´s there are so called selectors those do actually still exits in 32 bit too also very important is that these 4 GB of possible "addresses" are not converted into that rather the representing PTE´s and PDE´s represent to a 4 KB page (in old normal 32 bit style) so going with that if you have 4 GB/ 4 k pages you end up in only using 20 bits ! (20 bits * 4k = 4 GB) a idea (very similiar to the discussion about 4 k sectors and 4 MB sectors with the harddrive(hdd/ssd)) would be just to increase the 4 K pages to 4 MB pages that would be 1024 times as much RAM the discussion about this are elder thats why that bit (PSE (page size extension)) was 1 candidate to pass that 32 bit limit the other candidate was the PAE bit (physical address extension) here is 1 catch PSE can extend the 4 GB by increasing the page size (even with a 32 bit PDE´s and PTE´s) in PAE mode PDE´s and PDE´s are 64 bit (yes even in 32 bit mode), that´s one of the reasons why PAE can address more then 4 GB of ram (to be more precise paging are mechanism´s there also some more things they play a role the CR3 register (also called the page directory base register) or the GDT, it would be to long to explain all but lets stay like this for now) so let us take the next important step in the old 32 bit system without PSE,PAE or "concrete use of segments", an app/executable had to use up the 4 GB ram because there was a user-mode (ring3) and a kernel-mode (ring0) there had to be a part in kernel mode and a other part in user-mode offsets are not a problem (as you can map a address like 0xFFFFFFFF to page 0 if you wanted) deviding the kernel mode and user mode is important, if that would not be the case every crash on a normal app/execuble would be a entire OS crash (BSOD or wrose) so the solution was simple usermode 0x00000000 - 0x7FFFFFFF - kernelmode 0x80000000 - 0xFFFFFFFF thats how the eldest 32 bit norms work it is not to bad to have kernel mode ram because many modules actually need space in memory (its not like an app is just made out of the app itself the app consits of many modules that also use ram internal) - also the video frame buffer often has a kernel mode area that takes memory for example so here we finally have our split 0x00000000 - 0x7FFFFFFF (2 gb) + 0x80000000 - 0xFFFFFFFF (2 gb) = 4 GB the app/executable now has the problem that it cant directly use the kernel mode offsets (it certainly use them but rather passiv (its some memory you need less in your app)) for this microsoft then made the /3 GB option in this one usermode has 3 GB and kernelmode 1 Gb (0x00000000-0xBFFFFFFF) + (0xC0000000-0xFFFFFFFF) = 4 GB but now the important part those offsets are not physical addresses ! actually you can map every of that "offset´s" to different places in memory (including the ones above 4 GB RAM) so thats why multiple applications/executables can use up the entire 64 GB of RAM (in j7n example he had 20 GB of 64 GB possible) thats more then 4 GB of ram and the proofes XP 32 bit can do it that way now we also have to mention the ramdisc solution, if you have like 20 GB of data and map then into the physical ram then the ramdisc use a chuck-wise solution it then maps for example 1 GB of that 20 GB data into an offset (that goes like fast) (when it wants the next part it just maps the next part - but it is chuckwise) now we have to mention the pagefile, in the pagefile windows stores memory data on the harddrive (HDD/SSD) when windows wants it use exactly that trick (it loads the data from the harddrive into that virtual offset) but this time there is an important differenz - the data is not from a RAM memory - it has to load that from the harddrive (and that is slow) for a SSD its faster - but still not as fast as it would be in memory so i guess some have reconized the increase in speed with SSD`s ? now you have a little more precision why this is the case so now to the part why a "normal app/executable" actually dont pass that 4 GB ram ram limit i already explained why it is rather like 2-3 GB ram + some kernel mode memory that is rather used like passiv but now the reason why it actually dont go beyond the 4 GB ram in "just one application/executable" here you have to know that all compilers form the past-now dont use segment selectors to pass that 4 GB ram i never seen a compiler that would be able to do so. probaly windows xp (even up to win10) dont have code for this either. but here is the thing normally in a code flow of a debugger you see a offset (or better called vitual offset this time) for the code flow it use a register called EIP (instruction pointer) - the E stands for 32 bits - for example only IP for 16 bit and REIP for 64 bit (R means 64bit) but here is the next catch ... the most common debuggers dont show the selector but for the code flow the CPU use a combination of a segment selector + virtual offset (the one you see in a debugger for example) this is called the CS:EIP combination - where CS is the segment selector (called the CODE SEGMENT(short CS) selector) EIP E for 32 bit and IP for instruction pointer now might be a good time to call out a wiki page about that: https://wiki.osdev.org/Segmentation that CS selector is 16 bits wide (in 32 bits) and 16 bits means 65536 possible selctors ... so the combination 16:32 or CS:EIP would be 65536 * 4 GB - that would be theoretical 262144 GB that it could select (+ you have 6 of segment selectors all in range 0-65536) but here is the catch windows (either xp - 10) dont use this to pass the 4 GB limit the only things windows actually did with these registers is that they point to small pieces of memory (like the EPROCESS structure) that is possible - but it leaves out the use to pass the 4 GB of ram limit by just using a few kilobytes with that method ... here is an example where microsoft accesses a small piece of ram using a selector : https://devblogs.microsoft.com/oldnewthing/20220919-00/?p=107195 (the problem with the way this is used, it not used that to pass the 4 GB ram limit, rather is use that as small memory storage) so the next step: back to the app/executable as mentioned there is no compiler that actually generate the useage of segmentation ... therefore you would need a specific app/executable that can do so - and that means chrome still would not pass the 4 GB ram limit (because it cant use segmention) (and then you also would need the windows operating system code also to control this kind of memory managment) also to mention is the FPU unit even the elder ones are 64 bit (or bigger) in modern cpu´s they are 512 bits (AVX) so actually you can make 64 bit moves in 32 bits or calculations, compessions like h.265 do so also some routines are written in the FPU, for example cpu intense sort mechanism´s - you might heared MMX, SSE ect. so in short 32 bit has 64 bit commands that it can use over the FPU unit (what is actually done sometimes) it can pass the 4 GB of ram over multiple app´s/executables it cant pass more then 4 GB of ram with just one app/executable - unless it use a chuckwise method (like the ramdisc) - the segment registers are actually not used to pass the 4 GB ram limit(that also goes for win10 32 bit) so i tryed my best to explain this as simple as i could

Are you sure???????? https://en.wikipedia.org/wiki/V8_(JavaScript_engine) Excerpt from Wikipedia. "V8 is a JavaScript and WebAssembly engine developed by Google for its Chrome browser. V8 is free and open-source software that is part of the Chromium project and also used separately in non-browser contexts, notably the Node.js runtime system. Other server-side JavaScript runtimes use alternative engines, such as Bun and Hermes. Wikipedia Developer(s) Google Initial release September 2, 2008 Written in C++"

Having now reviewed things, I've come to the conclusion that increasing the apparently available RAM won't do anything at all to help with my crashing browser. Correct me if I'm wrong, but from what I've researched, the problem is fundamental, and it's because it's a 32-bit browser on a 32-bit system. My understanding now is that 32-bit processes are limited to accessing 2GB of RAM, and that remains the case regardless of how much RAM is on the system. All the RAM patch will help with is running more processes simultaneously, it won't help at all with giving more memory to individual processes. The Facebook browser tab is constantly running out of memory because of the FB Purity add-on, which is eating huge amounts of it. It appears that there's nothing I can do about that. Although it caused other problems, unfortunately, the only thing which helped was using the /3GB switch in boot.ini, which I gather allows a process to access 3GB of memory instead of 2GB. I've tried using the /3GB switch with the extended RAM patch, but the system then just BSODs on startup, so I assume that configuration isn't an option. Am I right here, and there's actually nothing I can do about the browser problem? Thanks, Dave.

The Microsoft update v6 restored on xp can't work today, it can't get to update page after I finished the process on the pages.

Intel discontinued SGX Attestation Service on April 2, 2025. So it is impossible to complete first SGX online verification using PowerDVD. According to the information from Blu-ray.com, a PowerDVD user failed to complete the SGX verification after replacing CPU. https://www.intel.com/content/www/us/en/developer/archive/tools/sgx-attestation-service-utilizing-epid.html

does limitmem.sys limit memory inside windows as well, or is it only for dos mode / dos applications? like i said before, i want the best of both worlds, also for maxphypsage, why is it a problem to use with rloew's patch? i ask because even when installing rloew's patchmem, i still have to use "maxphyspage=48000" or else the system doesn't operate correctly and / or may have boot problems, etc. It has been a long time since i've tested this, so it's not clear why this is the case, considering i've seen people use more than 1.128 GB of ram without issue with rloew's patchmem, but in my case, even with minfilecache/maxfilecache set to at least 1/24 of system ram made available / installed, it doesn't change the problems. and it appears that i only gotten a relatively modest improvement with rloew's patchmem, in terms of being able to use up to 1.128 GB of available system memory, as opposed to only 1 GB on unpatched systems, specifically with using "maxphyspage=40000". for more than 1.128 GB, i still had to use "maxphyspage=48000", as the ram installed was higher than that, and thus caused problems. The only thing i can see here is that limitmem.sys appears to do some kind of dos related functions that "maxphyspage" does not do, but still limits max available ram once booting into windows, so this appears to be why you are saying to use it instead of "maxphyspage" settings? however, would this then allow me to set a limit past 1.128 GB or is the 1.128 GB limit not fixed by the limitmem.sys being loaded in config.sys? i couldn't find "burmem" from my searching, and "xmsres" was too broad, so we are left with the other stuff.

I installed vista on my computer (Specs: i5-8400 MSI B360M PRO-VDH Radeon RX Vega 56 NVMe (windows 11) SATA SSD (windows vista) SATA SSD (macOS Tahoe) 2x SATA HDD (media) ) The installer boots fine and installs fine but when trying to boot vista it restarts after crcdisk.sys what shall I do?

It's well hidden: Settings / Privacy and Security / Manage V8 Security (near bottom of page - scroll down) / Don't allow sites to use the V8 optimizer (This will slow down Javascript) Really old Chromium versions (360EE) don't have V8 and so are (presumably) not vulnerable

(Actually Moonchild said:) Good; so the "collective punishment" of being banned for living in the wrong country will end soon, hopefully. MC is wrong about one thing though: As noted here, Anubis unfortunately does require one more thing beyond being "a little patient the first time they visit:" turning off certain privacy guards. MC himself won't abuse this requirement: ... but other Anubis-protected sites may not be so civic-minded, and how's the end user supposed to know? One user presented a possible workaround though: I don't know if MC has Anubis configured this way, but those outside the geoblocks may experiment at their leisure.

*facepalm the vista experiment among id*** if i have to write it like so ...

I personally use SAB for deskband support (as well as small taskbar).

That's funny. This covers about 90% of my account creations, these days. Yeah, I'm sure you just spiced up some fond memories. Congrats, on crossing the Rust threshold. Good to see it being put to good work ;) I am capable of patching. Without an overall solution, I could manage where ever I invested the time. Time seems to be the killer, of many projects, lately. The list would be huge. But, were talking about play, not practical. RemoteAdmin (older Win9x ver), Telnet, BBS (likely COM to IP [Telnet] servers), HTTPDs/FTPs, KDX/Hotline, etc. Many things needing both the servant(s) and client(s). It is just a matter of whim, before you find something (old) you want to try. Peter Tattam's Trumpet Winsock v5, already supports IPv6. But, it was commercial and may have only supported an older version of Winsock. Version 3.0d only supported Winsock 1.1. Here is a link from archive.org, with no security exception required. I don't know if it can still be registered (an email is provided for registration questions). But, it also requires that the machine date be set back (pre-registration) otherwise the shareware time bomb prevents if from loading. It may not work on WinME at all. Yes. this is the crux of the situation. If one created a new Winsock, then maybe support for legacy applications might be included. Off the top of my head, this wrapper idea was the cheapest/dirtiest fix. Yes, you are right. It seems to be "IPv6 only" only in some locations (Tuvalu). There isn't much clear indication, if overall IPv6 adoption would end IPv4. It is almost meaningless, if you are using modern software. The transition would cause no real noticeable difference (with most users anyway). Some are of the opinion that IPv4 will be here to stay, anyway. But, I'm not convinced that this is the case. Their argument is that, we are (many of us )already behind shared or fake IPv4 addresses; and why would ISPs give up that level of network access (IPv6 potentially being more direct IP to IP). My theory, of the practical nature of the thing, is that overall IPv6 adoption would be a good time to implement new legislation(s) about using only secured devices over the Internet. Meaning, that if you are connected, the devices must indicate/authenticate the users "real/legal" identity. IPv6 is certainly capable supporting this, for even multiple devices out of a single household. So, it may be a near mute consideration. Near, because I still see the potential to run legacy devices over such a connection infrastructure. It would likely just depend if that sort of thing was allowed (probably country dependent legislation). I can see the potential argument that insecure devices can allow insecure activity (vulnerabilities). But this is just a theory and, if a viable reality, probably a ways out yet. Its more likely to be seen in China, without a doubt; however, Digital Identity is still voluntary there.

It's interesting that I appear here right now (found this organically, created an account to reply). One of my hobbies that's gone on for far too long is to make MSN Chat (IRCX) work like it did in the 1990s. There's been many projects in various languages and I've done both server and client side stuff. Just recently, I started down the track of trying to get the MSN Chat control working in a Rust application. From what I can tell, it seems no-one has made ActiveX controls work inside rust (without using C bindings). Anyway, I somehow managed to get it working (I must have some idea what I'm doing), and then I thought what can I do to enhance things? One of the answers was IPv6! It's completely feasible to patch (either a binary file or a in memory) software to work with IPv6. In most cases, you'll want to create an IPv6 socket and set it up as a dual stack socket (supports both IPv4 and IPv6). I'm not going to lie, it takes a bit of digging (reverse engineering) to find what you're looking for, then a bit more effort to patch each relevant part, but I managed to do it in a few hours. Here's the relevant issue: https://github.com/realJoshByrnes/msnchat-rs/issues/4 (Attempt to patch in IPv6) with commits showing the changes made. Is there a particular software you're concerned about? I just thought more about this, and since it's in the 9x section I should probably add that patching IPv6 on an OS that doesn't support it might be tricker as you'll need a custom network stack or IPv4 over IPv6 tunnel. I believe there was some native support in NT4 and Win2k via an addon. P.S. Starlink has IPv4.

https://github.com/advisories/GHSA-mj9c-f5v6-7665 Severity: High (8.1/10) https://chromereleases.googleblog.com/2025/06/stable-channel-update-for-desktop_30.html Manual mitigation, at the expense of performance, if you don't want to update: https://github.com/Alex313031/thorium/issues/1024#issuecomment-3038992237

New release 132.0.6834.226 R5. This release was expedited to cover critical vulnerability CVE-2025-6554 (#1486). Some other changes were made: (#1480) - "Web Scrobbler" extension should now work on Windows XP, as well as other extensions that create notifications (#1473) - Favicons should no longer slide out of tab bounds when dozens of tabs are open in a given window (#1483) - Support for custom tab and new tab button shapes that are derived from an scs file are disabled by default after some users experienced performance declines after their introduction. This functionality is now gated behind the --enable-advanced-customization switch. Unless someone tells me that CVE-2025-6554 (#1486) is really important, I think I'll pass on this one.

It's ‎macOS, not relevant.

Figured it out. When you regular Windows taskbar settings > Taskbar behaviors > Unchecked "Show my taskbar on all displays"

Hello, who are you responding to?