All Activity

Only to (hopefully) clear the matter. The 2.2 Tb original limit depends on the 32-bit size of the MBR partition table that sets at 2^32-1=4,294,967,295 the max number of sectors accessible.[1] If the disk exposes 512 bytes/sector the limit is then 2.2 Tb. If the disk exposes 4Kb/sector size (so-called "Native 4k" disks) the limit is 8 times that much. What a number of USB external enclosures (the controllers in them) do is to expose on the USB connection the disk as if it was a Native 4k one, i.e. it makes the XP believe that the disk has 4 kb/sector, thus allowing to use "normal" 512 bytes/sector disks of much larger sizes than 2.2. Tb. The chosen method of alignment (to the cylinder up to XP, to the Mb on Vista and later) is unrelated. jaclaz [1] only for the record, at the time I devised a partitioning schema with two (or more) partitions that allowed to use MBR disks up to (almost) 4.4 Tb, but (a few) actual tests led to the conclusion that while the schema did work on later OS (7 at least) it did not work on XP due to some other limitation (still 32 bit related) in system files.

Select Monitor Scaling and Exit to DOS. This should retain the setting. Then use a DOS Vesa 3 app to set the mode and refresh rate. If it still doesn't work, the problem is definitely the video card not correctly supporting Vesa 3 on the DVI port. What DOS app are you using for your tests? BTW, both are 16:9 so there should be no black side bars. If the preview is like what you get, then it is correctly previewing incorrect behavior.

Ok, thanks, @ED_Sln. Now we will wait for any other user with such problem.

Microsoft VPN will surely work with Bing.

It's only when you connect the HDD via SATA directly to the Mobo, but it would mean it's NOT external anymore. It's internal.

No, wrong, it depends on the year of manufacture. I had dozens of such 4TB drives made by WD, produced somewhere in 2014 - 2015. All worked as intended.

Yes, I tested with chrome-xpapi-adapter.5062.2.for.testing. But again, I was testing in a virtual machine. I can also test on a physical computer with i7 3770 with 8 threads. Upd: Tested it on an i7 3770. The result is the same for the original progwrp.dll and chrome-xpapi-adapter.5062.2.for.testing. On tests: Aquarium 500 fish, 5 fps, CPU load on average 70%. AV1 1080@3000 - 17% CPU load on average.

As far as I know even external ones couldn't be read because XP 32 bit couldn't handle partitions bigger than 3TB. Or at least that's what I kept hearing back in 2009 or something.

Nice, but only if Microsoft will flatten to the ground those pesky sites that always want to see your IP so they can track you. Cloudfare, for example. Otherwise - useless, and it looks more like a marketing strategy. If such sites will still block that VPN, too, this whole idea serves no purpose to us.

What makes you think I didn't understand? You wrote "external". External ones always worked because they were meant to - by using a conversion chip on-board.

Ok, its fine. I hope you are also done that testing with my build, created for testing (it has some changes in CPU detection code). But because the problem was only with *some* of CPU types, it can be no differences with my previous adapter builds, which also handles multicore CPU's properly. https://github.com/IDA-RE-things/Chrome-xp-api-adapter/releases/download/v1.2/chrome-xpapi-adapter.5062.2.for.testing.zip So we waiting for another user, which will have such differences, if there are. (except 66cats).

Running a VM not necessarily for remote access. There are programs that can run VMs, I use VMWare Player. The issue you had is that you don't have a lot of storage space. Offloading where the OS is located to another machine on a VM would alleviate that issue because you would be using disk space on a different computer. Running an emulator/hypervisor on the device and then making a VM to run inside of it does not solve your issue. Why do you need OSX? Think or Swim runs on Windows. And since that is a serious business software, it may be better to pay the price of doing business and buy/use something with a larger hard disk.

You didn't understand my post. It's been said many times that XP 32 bit can't read HDDs that are bigger than 3TB and you have to patch the OS or something as a workaround. I'm stating that XP 64 doesn't have that issue. Second thing I said is this. If the partition is made on Windows 7 or newer it's already aligned in 4K sector. There's no conversion involved when you use that drive on XP. The difference is this. You shouldn't partition the drive using XP because then you will end up with 512k sectors. And yes the drive will work. But there will be performance loss because of the conversion on the fly. Sorry I wasn't clear enough.

WebGL test with the original progwrp.dll showed exactly the same results, both in CPU load with different number of cores and in fps, as well as on 6 was 4 fps, and on 12-16 - 3 fps. The av1 video test also has the same CPU load with both dlls.

Ok, is the result nearest same as it is with original progwrp.dll ? If so, then all ok. If no, I will do more investigation of differences in code of functions. Because I have only 4-core max CPU on my side. And all works fine for me. And another one: Can you compare also AV1-video decoding with it (about loading of Cores, and entire process of playing it, it should be without freezes ets. (compared to original dll lib)). We have such test links: https://bitmovin.com/demos/av1 https://test-videos.co.uk/

I checked it in a virtual machine with 6, 12 and 16 cores. With the increase of cores the load only decreases. But the fps even slightly decreased, on 6 cores it is stable 4, and with more cores - 3.

At least no one bothered us with their unnecessary comments, and this also helped. It is not necessary to show off the entire process of problem solving. For those of you who have been analogous multicore-handling problem, can test intermediate version of adapter (not fogot to rename to "chrome-xpapi-adapter.dll") : The problem was in detection of *some* CPU's (not all) as single-core instead of multi-core. And now should be fixed. https://github.com/IDA-RE-things/Chrome-xp-api-adapter/releases/download/v1.2/chrome-xpapi-adapter.5062.2.for.testing.zip And try onother one test, Which should show how many cores loaded. Should be loaded all possible cores. https://webglsamples.org/aquarium/aquarium.html Should be runned w/o hardware acceleration (i.e without switches like --use-angle=d3d9) to be handled only by software.

Two pages of back & forth, debugging my HW issue (still unresolved). Didn't want to derail this thread.

When I first read that, my thought was "uh oh, another false positive", lol.

Thank you for the info! I may wait a bit to see some feedback in regards to this issue. Hopefully it's fixed.

Just to make something clear, my aim is to use this mini-PC in front of me not remotely. Someone was telling me that running a VM setup is for only remote access to tap into another computer. But I'm not looking to do that, so I'm trying to have the Win7 installed then another 3rd-party program installed into that to be able to run an OSX Mojave ontop of that so then I can install the Think or Swim platform which is the ultimate goal of this process. Does "ESXi and Hyper-V" do this? act as that 3rd-party program? I was told to look into Proxmox as well. I will be studying up on this over the next week or more. I saw some YouTube tutorials saying to not Hackintosh a system if going the OpenCore or Clover route and that there is a much simpler way of setting up a Hackintosh virtually, but I'm not sure if they meant by the Hypervisor way. If you know of any other way, a 3rd approach to getting an OSX onto a daily-use mini-PC I would appreciate that advice as well, thank you.

Probably a very good idea, I recently had so much trouble with a simple search on DuckDuckGo from my real London IP. https://msfn.org/board/topic/186217-solved-xcom-failedscriptvendor/?do=findComment&comment=1266413

Why private? You aren't hiding anything from us, by any chance, are you?

DirectAccess is the latest feature to hit the list of deprecated features in Windows client and server editions. For those unfamiliar, DirectAccess was introduced in Windows 7 and Windows Server 2008 R2 as a new method for clients to connect to their corporate networks without installing a VPN. However, with time, Microsoft developed new network capabilities to improve the experience, and now it is ready to replace DirectAccess with a better alternative. According to the official documentation, Microsoft suggests migrating from DirectAccess to Always On VPN: DirectAccess is deprecated and will be removed in a future release of Windows. We recommend migrating from DirectAccess to Always On VPN. Microsoft has a dedicated page that describes why users should move from DirectAccess to Always On VPN and how IT admins can implement the change. You can check it out on the official Microsoft Learn website. Besides DirectAccess and NTLM, in 2024, Microsoft deprecated Driver Verifier GUI, NPLogonNotify and NPPPasswordChangeNotify APIs, TLS server authentication with short RSA keys, and Test Base for Microsoft 365. As a reminder, deprecated and removed features are not the same. Components that are no longer in active development may remain in the operating system for a while and even continue to work. However, they do not receive new functionality or fixes. Eventually, Microsoft deletes them from Windows, as was the case with WordPad, which is no longer part of the upcoming Windows 11 version 24H2 update. You can track the list of deprecated features in client Windows versions here. Recently, we also published a list of features Microsoft no longer develops in Windows Server 2025, so check it out here. Source: Taras Buria · Jun 11, 2024 17:22 EDT · HOT!6 https://www.neowin.net/news/microsoft-to-remove-directaccess-from-windows-recommends-switching-to-always-on-vpn/

VBE 3.0 support is generally available. But in the case of DVI, this is not enough. We need something else. Or something interferes with full-fledged work (What exactly?). This generally exists and works fine over a VGA connection. At least in combination with some VBE 3.0 compatible nVidia-based cards, such as NV30, NV31\NV34 (Only some vBIOS implementations actually allow this capability) , and NV38, from the ones I've tested. For the first three, the UniRefresh utility is suitable, and for NV38, the patched UniVBE is suitable. However, in none of these cases is it possible to change the refresh rate exactly when DVI is connected (Always remains 60hz). As for the G70, which I'm tormenting at the moment. Using a DVI connection under DOS, it always remains 60hz by default (Or another value that is explicitly specified in the monitor's EDID (In the Preferred Timing Block)). And it doesn't change to anything else with the help of these utilities. Alas! As specified in this EDID block, it remains under DOS in all cases (and in the DOS window of Windows 98, too). I should probably try switching back to NV34 (where VBE 3.0 is guaranteed to work via a VGA connection) and think carefully about why this doesn't happen with DVI... What else can I try to do? Here by the way there is a link to this: "Bit 11 Refresh rate control Select. If set to 1, use usеr specified CRTC values for refresh rate, otherwise use BIOS default refresh rate." Maybe somewhere you need to switch to 1 by hand? This is via RU.EXE is it changing or is it being changed in vBIOS? If the former, how do I get to this place? I would like to see what the G70 value is now.