LLXX

Why Vista? Because many users just want the newest OS from Micro$oft.

Version 1.1 available for download As mentioned in http://support.microsoft.com/?id=318293 Windows 98SE shell fails at trying to copy files over 2Gb. According to M$... ...the problem is with shell32.dll.Unfortunately, M$ is only partially right. I've inspected and traced through the copying code in shell32.dll, and the actual problem seems to lie within the kernel itself, at the _llseek API. 7FCEB349 mov [ebp+nNumberOfBytesToWrite], eax 7FCEB34C mov eax, [edi+20h] 7FCEB34F cmp eax, 30000h; over 192Kb in size? 7FCEB354 jbe short 7FCEB386; no pre-enlargement if not 7FCEB356 push ebx; iOrigin 7FCEB357 mov ebx, ds:_llseek 7FCEB35D push eax; lOffset 7FCEB35E push [ebp+hDestFile]; hFile 7FCEB361 call ebx; _llseek apparently has problems seeking over 2Gb 7FCEB363 cmp eax, 0FFFFFFFFh 7FCEB366 jz loc_0_7FCEB55D; fails here 7FCEB36C push [ebp+hDestFile]; hFile 7FCEB36F call ds:SetEndOfFile 7FCEB375 test eax, eax 7FCEB377 jz loc_0_7FCEB55D 7FCEB37D push 0; iOrigin 7FCEB37F push 0; lOffset 7FCEB381 push [ebp+hDestFile]; hFile 7FCEB384 call ebx; _llseekFor those that don't understand the above code, what it does is attempt to enlarge the destination file to the correct size by seeking to the source filesize and then setting the file's end there. Unfortunately, if the file is >2Gb, _llseek fails with "invalid parameter" error. Also note that unless the file is over 192Kb in size, no attempt to pre-enlarge is made - the file just enlarges automatically as data is written to it. Either the bug is with the _llseek function in the kernel and the code in shell32 is fine, or _llseek was designed to do that (i.e. interprets >2Gb as moving the file pointer backwards, but the pointer is already at the start of the file so it complains) and shell32 is flawed. I can see several possible fixes: 1. Patch shell32.dll to use newer SetFilePointer function which uses 64-bit signed integers - difficult, but possibly the most "correct" solution. 2. Patch kernel32.dll _llseek to interpret seeking from the beginning with a negative offset as a positive offset - moderate, might break some other apps, but what program would want to move the file pointer past the start of the file? 3. Change conditional jump at 7FCEB354 to a permanent jump - easiest, but no more pre-enlargement - is pre-enlargement really needed? ------------------------------------------------------------------------------------------------- Update: Fixed kernels: 4.10.1998 4.10.2001 4.10.2222 4.10.2225 4.90.3000 (kernels are too big to attach) Verification Tool: MAKE2GB.ZIP

Look at the volume label and http://wiki.djlizard.net/Product_IDs

Heatsink is firmly secured and in good contact with CPU?

Thanks LLXX, do you also happen to know if it uses 1, 2 or 4 sector(s) cluster? (the 1.68 DMF format differed from "normal" 1.68 as it had two sub-versions one DMF1024 with two sectors clusters and DMF2048 wit 4 sectors clusters) jaclaz I only tried to recreate this format, so I'm not sure of the original. I used 64 sectors/cluster. Here is Diamond 1.00.0520 and doc: http://dump.stoleyour.net/uploads/07cdc9948f.zip

Why'd you make 3 threads about this? Drivers are specific to OS, WinME version probably won't work on 98SE.

I already fixed 4.00.1119 a long time ago, it's here. At first, I was wondering about the NOPs as well, thinking that they'd presumably be for I/O delay purposes, but as the original code does not have any other instances of I/O instructions separated by so many NOPs, I decided to ignore them, and the code of the patched version ended up having delays between the OUTs in any case. The driver works fine without them anyway.My driver does send an extra zero to the sector count register, and this is not needed for LBA28 commands, but is for the LBA48, and at the time I couldn't think of a better place to put it. Yes, this does decrease performance for non-48bitLBA commands, but the additional ~30ns delay is unlikely to be noticeable as the actual command execution time is much greater.

It looks like that program installed an incompatible shell hook. Have you tried uninstalling it? Next time, test out programs in a virtual machine (M$ Virtual PC 2004 is free) before installing them on your real machine if you don't know how to unpack installers and install manually.

I think you should take a look at the Unattended Installs forum.

Use a slightly moist cotton swab to clean the lens, with water is fine but there are lens cleaning fluids (intended for camera lenses) that are recommended.

...ask Micro$oft.

ProductKey= entry in msbatch.inf

Free hard drive diagnostics program: http://hddguru.com/content/en/software/2005.10.02-MHDD/

If the pagefile is not set to a fixed size, there is a large chance that it'll become fragmented when it resizes. That decreases performance considerably. I use 1024/1024 on all my machines, XP, 98Se, and Server 2000, haven't had any problems so far.

Definitely shorted out the USB controller and damaged some other circuitry on the mobo. Next time, ensure the port and plug are both clean, and insert it straight and in one continuous motion.

Backup your data anyway.

The shift key does not repeat. And, according to the PC Technical Reference, 0417 is the only address with the state of the shift keys (lower 2 bits). The other bits there are for Ctrl, Alt, ScrollLock, NumLock, CapsLock, etc. It only looks like it's repeating because XP's DOS emulation is awful - the state of the shift key is being reported erratically. I tried with a similar batch file under Win98 and it works perfectly fine. @echo off :loop shiftkey if errorlevel 0 set errorlev=0 if errorlevel 1 set errorlev=1 if errorlevel 2 set errorlev=2 echo %errorlev% goto loop Maybe an equivalent Win32 program might work better, but then again, it is difficult to get realtime key states in multitasking OSs anyway. If you want, I can write the Win32 program.

http://www.adrc.net/data_recovery_software/index.html Free data recovery tools.

That would be rather difficult, but first there is a 2Gb barrier in copying files that has to be fixed first. I will attempt to fix problem described in http://support.microsoft.com/?id=318293 by patching a shell32.dll. It should not be too difficult as this is just a standard programming error of using signed instead of unsigned comparisons (the programmer must've thought files could have negatives sizes )

Very useful! I see there is a general interest in making custom 98se distros now.

Thanks for the thumbs-up. Well, that explains the size of the cabs; I suspect that this format, along with the DMF format, have abbreviations in makecab (like the the other floppy sizes) which aren't mentioned in the "documentation." Then again, there's a lot that's not mentioned, or mentioned only in the most obscure manner, in the makecab documentation. The abbreviation is DMF168.Also, I have found what appears to be the 'full' documentation for Diamond , as well as Diamond.exe, from an old Java SDK. Diamond must be the original program used by M$; unfortunately, the documentation and program are from 1994 so it probably does not have newer features, but supports a "Quantum" CompressionType. If you want I can upload it somewhere. Quite a coincidence that MakeCAB and Diamond are both exactly 7 letters long. Here are some of the interesting strings from Diamond.exe: 681984000 65535 CDROM DMF168 1716224 2048 16 1.68M 1457664 1250304 192 1.25M 1213952 512 224 1.2M 730112 720K 362496 1024 112 360K Set Option New InfWriteDisk InfWriteCabinet InfWrite InfEnd InfBegin Dump Delete Define UniqueFiles SourceDir setup.rpt RptFileName ReservePerFolderSize ReservePerDataBlockSize ReservePerCabinetSize 20 MaxErrors MaxDiskSize MaxDiskFileCount MaxCabinetSize DCF InfSectionOrder InfHeader6 InfHeader5 %1** Diamond Version: %3 InfHeader4 InfHeader3 InfHeader2 InfHeader1 InfHeader InfFooter4 InfFooter3 InfFooter2 InfFooter1 CompressionMemory CompressionLevel CompressionType Quantum Compression Level not in range (%1..%2): %3 Compression Memory not in range (%1..%2): %3 Microsoft (R) Diamond Disk Layout Tool - Version %1 Copyright (c) Microsoft Corp 1993-1994. (32) 1.00.0520 (12/16/94) Compression will be slower. A few quarts low on memory. Compression will be much slower. Critically short of memory. From the documentation:

The actual frequency of the 2600+ is 2083.333... MHz.

The temperatures are fine. Try removing all the video devices (in the Device Manager, view hidden devices) and reinstalling your driver. http://downloadfinder.intel.com/scripts-df...al〈=eng

Indeed, XP 'formatter' is a joke. All the formatting I do is with Fint13 from DOS. A special driver is not needed to support >18 sectors/track, just set the floppy in BIOS as 2.88Mb. 1802240 is the formatted capacity, just like a "1.44Mb" floppy actually has 1457664 usable bytes but 1474560 actual bytes in sectors. 1802240 bytes = 3520 sectors of usable space + 512 bytes = 1 sector for root directory + 1024 bytes = 2 sector for 2 FATs + 2048 bytes = 4 reserved sectors + 512 bytes = 1 sector for superblock = 1806336 bytes = 3528 sectors total

VB or C#.. not much difference during runtime. You know, that funny little thing called the CLR. VB.NET, that is. "Classic" VB is just a little more bloated than C++.Me, I prefer pure win32 API