Leaderboard

Notice: so upstream released new version yesterday, and tracking is completed. hopefully new UXP based build will be available in this weekend.

This thread is now locked. These types of arguments will never be resolved, and MSFN isn't the place for them, even in this section.

Hi @windows2. Dual booting Windows 95 and NT was common back in the day. Your Intel pentium 2 is a classic. For the most part this old hardware is solid. Probably the most common failures are hard drive and power supply. If you want to hang onto this system for a long time, recommend picking up these extras when you find them, not overly expensive. Another option if your BIOS and hardware supports booting from more than one drive. Consider purchasing a second drive for Windows NT. Physically remove the Windows 95 drive while installing Windows NT on the second drive. Re-install both drives after the NT install. If you don't want to install a boot loader and your BIOS allows, select which drive to boot using the BIOS boot screen. Main point, since the system and Windows 95 install is nostalgic from your father, first thing should be to make a full backup of the C: drive using your favourite backup software. Then muck around as much as you want, won't lose any data or important configurations.

My glasses are blue!

https://forum.palemoon.org/viewtopic.php?f=61&t=26963&start=60 you may try mobile version instead

I'll admit that I'm straying from the conventional/Microsoft-prescribed way to multi-boot NT and DOS/9x in utilizing NTLDR's flexibility here; and if you do it this way and NTLDR and its associated files are located on an NTFS partition, you won't be able to access them from an OS without NTFS support should they somehow become corrupted—probably why putting them on a DOS-accessible FAT16 partition has been commonly suggested, like on the BootPart site. But you could always make an emergency boot floppy by formatting a floppy in NT (this is important) and copying NTLDR and associated files (NTDETECT.COM, boot.ini, any boot sector images you're using, and ntbootdd.sys if present) to the floppy, and use it to boot should the need arise. I do personally like the idea of being able to utilize NTFS's file permissions with the bootloader files, to help protect them when not logged in as an administrator. Having just tested BootPart a bit, this does seem to be a really good choice for a utility to make the approach I suggested easy; and its method of generating special "boot sector" images that chain-load partitions' actual boot sectors (as I've now confirmed is the case) is arguably better than simply saving copies of the boot sectors as the images, should the actual boot sectors need updating later which would otherwise require you to re-save them to the image files to keep those in sync. In the O.P.'s case, assuming that the second partition with NT is the "active" partition and contains NTLDR and associated files (and that installation of NT has been successfully completed), and the first FAT32 partition with Windows 95 is unmodified (i.e. boots correctly when set as "active"): when running NT, you would first run BootPart with no parameters to list all partitions and see which number corresponds to your 95 partition (likely 0 since it's the first partition). Then you would run it like this (using 0 as an example number): bootpart 0 C:\bootw95.bin "Windows 95" BootPart adds an entry to boot.ini for you, using the last parameter as the name to be displayed in the boot menu. (If you omit the last parameter, it just generates the image without updating boot.ini.) When you later choose the "Windows 95" option in the boot menu, NTLDR will load and execute bootw95.bin, which loads and executes the boot sector of your Windows 95 partition, which then proceeds to boot 95 as normal.

In my humble view, a shout-from-the-rooftops NO, this test can NOT be trusted. I say that because I can get THREE DIFFERENT RESULTS all in the same exact web browser from the same exact computer on the same exact wi-fi network. Change a NoScript or uMatrix setting and the test "result" CHANGES. So that is NOT a "unique fingerprint", plain and simple. HOWEVER, just narrowing a "fingerprint" from thousands down to THREE does still basically have you "identified". So I guess the answer is "yes and no".

ALL browsers are KEYLOGGING your replies in this MSFN reply box. I'll demonstrate using 360Chrome but again, ALL browsers have a KEYLOGGER for this MSFN reply box. Most likely in other forums also, especially if using the same "forum software". For my 360Chrome profile, that KEYLOGGER is being saved here -- <root folder>\360ChromePortable\Chrome\User Data\Default\Local Storage\leveldb\000022.log My 360Chrome loader deletes this file each and every time that I exit, otherwise this 000022.log file would have text from "years ago". Please note that username and password input fields are NOT being keylogged, only this MSFN reply box. I don't see this as "nefarious", you have to be a member here and you have to be logged in, but it is still a "feature" that is "concerning" to some.

Couple of notes here: 1. You say that you have a "6 GB" partition with Windows 95, followed by a "4 GB" partition that you want to install NT on. This is potentially problematic, as NT 4's version of NTLDR, with a normal configuration (not using an NT storage miniport driver to access the partition), can only access the first ~7.8 GiB (~8.4 GB) of the hard drive; and if the NT kernel or other binaries loaded by NTLDR end up located past that point (e.g. after installing an update or new boot-time driver), booting will fail. Therefore, the partition on which NT 4 is installed should be contained entirely within the first 7.8 GiB/8.4 GB of the disk. (Note that even a 1 GB partition is large enough to contain NT 4 itself plus some programs.) Once NT 4 has booted, however, it can access the entire extent of the disk without issue provided that the storage driver in use supports it. 2. If it were me setting this up, I'd just let NT 4 take over as the primary/"active" OS partition, and manually add the Windows 95 FAT32 partition as an option in the NTLDR boot menu. This is done by placing an image file of the target partition's boot sector in the root directory of the boot partition with NTLDR/boot.ini, and adding a line such as C:\bootw95.bin="Windows 95" to boot.ini (if you name the boot sector image "bootsect.dos", you can omit specifying the filename and just write: C:\="Windows 95"). NTLDR simply loads the boot sector from the file and executes it, and the boot sector is then responsible for loading the OS or boot loader from its corresponding partition as normal. You'll need to procure a suitable boot sector image yourself, using a disk editor or other utility running on NT to save the first 512 bytes of the target partition to a file, or perhaps using Gilles Vollant's BootPart utility, which I haven't yet used myself but which seems to be a good choice (sounds like it doesn't save the actual boot sector of the target partition to a file, but generates a special boot sector image that chain-loads the boot sector from the actual partition). Following this, if you want to be able to access the FAT32 Windows 95 partition when running NT 4, install the Winternals/Sysinternals FAT32 driver.

The issue is then the following. Normal Windows 95 booting: BIOS->MBR->PBR(of active primary partition)->IO.SYS Normal Windows NT booting (normal or in dual boot): BIOS->MBR->PBR(of active primary partition)->NTLDR->BOOT.INI choices(if any)->either Win95 or NT in this case What likely happens in your case: BIOS->MBR->invalid PBR (as it doesn't exist in NT the concept of FAT32 filesystem)-> a suffusion of yellow or BIOS->MBR->PBR-> NO NTLDR(as it doesn't exist in NT the concept of FAT32 filesystem)-> a suffusion of yellow Possible workarounds: 1) creating an additional (small) FAT16 partition 2) converting your existing C: to FAT16 3) using the Windows 2000 (or possibly even XP ) version of NTLDR and NTDETECT.COM (as these do understand FAT32) 4) using grub4dos to chainload the NT NTLDR (that must however reside on either a FAT16 or NT NTFS filesystem or in a (floppy) image #1 is the most "natural" way BUT you might have issues with drive lettering (that can BTW solved, but far from easy-peasy) #2 is fine, but it will deprive you of some advantages of FAT32 over FAT16 (smaller cluster size), and anyway the 6 GB are "too much" for FAT16, so you would need to shrink it to around 4 GB, and in any case it would have a huge (64K cluster size). #3 would be the easiest/next "normal" approach, #4 while being (slightly) more complex is the "less intrusive" one in the sense that it can be tested without changing anything in your partitioning. Personally I would advise you to try #4 first, because should it not work for *any* reason there are not any complex changes to partitions, filesystems etc., and thus no damage to existing install of windows 95. Brief instructions for #4 Get latest grub4dos from here: https://github.com/chenall/grub4dos/releases from the package extract only grub.exe and copy it to the root of your C: Boot to Windows 95 command prompt and in it run grub.exe. You should get to a grub> prompt. In it type: root [ENTER] and take note of the output, should be (hd0,0) find --set-root /ntldr [ENTER] root [ENTER] and take note of the output, should be (hd0,1) if the D: partition is primary or (hd0,4) if it is a logical volume inside extended cat --hex --skip=446 (hd0)+1 [ENTER] you should have two lines "populated with data" and two lines with 00's and a final 55AA If everything is as above, try: chainloader /ntldr [ENTER] you should see something *like* Will boot NT .... boot [ENTER] What happens? (there might be an issue with "sectors before" in the logical volume PBR/VBR that may need to be corrected) jaclaz

StartAllBack 3.2.2

Attachment for @Wunderbar98 . Spellforce for win 98 and up. This is what it should look like. b20 folder with .bsi files is inside of the "skinning" folder. speech is inside sound terrain , water inside texture. Predefined , Starterkit inside figure_template campaign ,Lan inside map All works fine . Look at the screenshot.

Chips progressed since my last check on 17 December 2018, so here's an update. ---------- Dram update The capacity only doubled in 3 years, to 2GB=16Gb per chip at Hynix (even 3GB), Samsung, Micron. Chips stack using Through-Silicon-Vias (Tsv). Fugaku has 100Flops/Byte because the faster Hbm2 on the processor socket limits the capacity. I won't imitate that. Other supercomputers offer 10-40Flops/Byte. I strongly advocate to spread the cores among the Dram for throughput and latency. One 2GB Dram can host 8 scalar cores (no Simd, one 64b FMAdd per cycle) at 2.2GHz for 18Flops/Byte. Each scalar core has comfortable 256MB Dram for OS subsets and application data. Or 16 scalar cores at 1.1GHz should save power. ---------- Flash update One 32GB Flash chip suffices for 2GB Dram. If a divided Flash chip stacked under the Dram can provide 600MB/s to each core, virtual memory saves the whole Dram in 0.4s, and data centers too improve a lot. If not, the 8 cores (or several sockets) can share a (stacked?) Flash socket nearby. ---------- Cpu update Intel is stuck at 14nm (10nm for chips not too big) and Amd buys its performance chips, but Tsmc produces 7nm processors, Samsung too. This improves the integation and power consumption over my latest update, and explains the Flops*2.6 from Summit to Fugaku: each A64fx Cpu socket holds 48 cores that compute sixteen 64b FMAdd (two 512b Simd) per cycle, while the whole Fugaku consumes 30MW or 0.24W per 64b FMAdd at 2.2GHz - maybe 0.15W locally. ---------- Divided Dram, split Cpu A divided Dram has a shorter latency. 8 sections, with address and data access at their centres, cut the distances by sqrt(8). Diffusion time over RC propagation lines explain the latency well, and then the latency is cut by (sqrt(8))2, so 50ns become 6-7ns, or some 15 Cpu cycles, excellent. The core needs only the L1 caches, no L2, no L3, saving almost 1/2 the silicon area. We could go further. 32 sections at 0.55GHz (waste silicon area) would slash the Dram latency to about 2 Cpu cycles to eliminate the L1 too. That's excellent for applications accessing random adresses, like Lisp or expert systems. Then instruction between 3 arguments in Dram, as the Vax-11 did, make sense again. To cut the distances on the Dram, each Cpu has its own chip and sits in the middle of a Dram section. Maybe some thick upper metal layers transport signals quickly on the Dram, but I doubt enough signals fit on the area. I expect many <1mm2 Cpu are cheaper than one huge many-cores. A 14nm or 10nm process can produce it at Intel etc, and then a slower clock and more Cpu would limit the consumption. Spare Dram sections can improve the production yield. A Bga socket suffices, I expect many ones come cheaper than one huge Lga. Cooling 8*0.15W is very easy. I displayed a switch matrix chip, the same as between the sockets, stacked on the Dram, but the Dram could integrate the function or the Cpu provide direct links. Stacking and splitting applies also to graphics cards, gamestations, desktops. Massive multitasking is necessary anyway and difficult enough. The scalar Cpu are easier to program and fit non vectorisable applications. I hope one sequencer per scalar Cpu is small and frugal. ---------- Dram to Cpu interconnect For easy programming, I want to restore the "golden rule": L1, L2... Dram throughput match the Cpu needs. Such a loop for (j blahblah) s += a[j]; or s += a[j] * b[j]; or even c[j] = a[j] * b[j]; can run within L1d of present processors, L2 of some recent ones, maybe L3, but not over the Dram, and this worsens over the generations. The older and smaller Xeon E5-2630L v2 computes on 4*64b (Avx-256) over 6 cores at 2.4GHz. a[j] needs 461GB/s, a[j] and c[j] too depending on the program. But 4*64b Ddr-1600 supply only 51GB/s. The Cpu must wait 9 cycles to obtain one a[j] from the Dram, or 27 cycles for a[j], b[j] and c[j]. The big Xeon Phi 7290 computes on 8*64b (Avx-512) over 72 cores at 1.5GHz. 6*64b Ddr-2400 take 60 cycles to supply one a[j], ouch. The recent A64fx get 1TB/s from HBM2 Dram on the socket, better. But 2*8*64b (two Avx-512) over 48 cores at 2.2GHz would need 14TB/s. The Cpu would wait 14 cycles for one a[j]. It's "Cy/T" in the table of 09 January 2022. To feed the Cpu, the programmer must find operations that use the data many times, write external loops that move data subsets to the caches and internal loops computing there. Slow L3 or L2 can demand intermediate loops. And some computations like an Fft just use data too few times. Separate Dram and Cpu create the horrible bottleneck at the worst place. HBM2 Dram on the Cpu socket improves too little. My answer is to stack a Cpu over each Dram chip and connect them densely. I explained there how to transfer enough signals scienceforums here's again the drawing. The chips carry solder islands smaller than we can align, and after reflow the chips assign adaptively the signals to the obtained contacts. The tiny islands consume little power to transmit the signals. Capacitive coupling can't supply power easily, alas. If Tsv were narrow enough, a stack of Dram could carry more Cpu. In my example, a scalar 64b core needs 3*64b transfers per clock cycle. With some links and power suply, that's 1000 contacts to the Dram at 2.2GHz (can be faster). If each contact takes (5µm)2, just (160µm)2 suffice on each Dram section and Cpu. Just 0.5µm etching suffice, even coarser at a demonstrator, and two Pcb make a poof-of-concept, so that's a nice university project. Ready? With estimated 15 cycles latency at 2.2GHz, the Dram can access data over only 15*3*64=2880b=360B to achieve the throughput. This relates with the L1 line size too. Close coupling between Cpu and Dram allow original useful accesses at full speed, as I described there scienceforums for (j blahblah) L1d[j] = Dram[j*n]; // Matrices, struct and many more or L1d[j] = Dram[bitreversed(j)]; // For FFT or also L1d[j, bits k] = Dram[k, bits j]; // For database filtering Dram access width being a prime number of bytes or words avoids most collisions in periodic addresses. Some primes like 28+1 or 211-1 simplify the hardware. Bit shuffling works best with transfer sizes multiple of 64 dwords of 64b. Marc Schaefer, aka Pointertovoid aka Enthalpy

Old computers have already been left behind by the raw CPU power required by modern websites regardless of the browser, and the hunger for memory of multi-process Chrome. A Conroe CPU is about the oldest that can be comfortably used, and it implements SSE3.

There are certainly some instances where a small company may have made a run of discs themselves and used CD-R and then put a label on it, I have seen it before. There are also times where a contracted company may have used CD-Rs in order to send media to companies, contractors for large companies who could afford pressed discs like Sony. The main issue with CD-R is that they do not stand the test of time as the organic dyes will degrade after many years, so it is not uncommon to find 20 year old CD-R not readable in a drive. But also consider that CD-R from that long ago used to have issues with how they were "mastered" or created that could effect how they could be read. The primary example was that sometimes CD-R could not be read in a CD player outside of a computer, but I do recall some other instances where some CD-R could not be read on a computer that didn't have (for example) Adaptec EZ CD Creator installed. I have never tried a Wii disc in a computer.

Here is a maintenance update of VxDProps.exe... the new version is 1.0.0.1, because changes are really minor. Here's what's new: 1.) Bugfix: now Language Neutral VxD's are described as such. 2.) New feature: now the DDK Version is also given. VxDProps_1001.7z