egrabrych

"Attribute Changer" v.6.20 is functioning correctly in Windows 98SE (+ KernelEx 4.5.2). At least with me But there are problems with the changes attributes of the files in multi-level folders structures (also in Windows XP) - but that is beyond the scope of this thread.

The list of files and folders contained on the CD "Windows 98 Resource Kit" - in alphabetical order (TXT file compressed in ZIP archive): Win98rkb.zip Maybe someone of you will come in handy

1) Open "My Computer". 2) In the "Address", type: ftp://ftp.microsoft.com/services/technet/samples/ps/win98/Reskit/DIAGNOSE/ 3) For Kill.exe file use the command "Copy to Folder". You will receive a file with the following parameters: Created: February 26, 1997 1:53:00 PM Modified: February 26, 1997 1:53:00 PM Only "Last opened" will be the current date and time. Alternatively, use this: http://www.petges.lu/download/

It was, it's been... It helps! Now Usbstor.sys 5.00.2195.6773 working properly Thanks! Indeed, I have a Wdmstub.sys file in version 5.00.006. Working with the earlier version did not check, because Wdmstub.sys version 5.00.006 is installed by Maximus Decim Native USB 3.5.

With me was not working properly Usbstor.sys file version 5.00.2195.6773 Helped downgrade to version 4.90.3000.1 But I have not installed U98SESP3.EXE - so I do not want to generalize. In NUSB 3.5 Usbstor.sys file is currently in version 4.90.3000.1

Is there any formal limit the size of the registry files Windows 98 SE: System.dat and User.dat? Thank you in advance for any information on this issue! egrabrych

I have a question: what about the letter "Ñ" in the name of a folder or file? Do Cmd.exe 5.00.2144.1 (original english version) placed in U98SESP3-esn.exe can open these folders / files? egrabrych

Looking at the different language versions SP2 and SP3 (other than "EN-US"), I met 16-bit files of type "NE" (e.g.: Krnl386.exe and Gdi.exe) that were in the revised language version, but information in the file description said that it is a version of "English". I suspect that these files were modified using eXeScope – a program which does not allow editing this information. Looking at these files in hex-editor, I noticed a certain regularity: block of information about a file ends of the word "Translation". At some distance it is followed by two adjacent groups of hexadecimal values, which are mirror image of the sequence values of ASCII, defining of the language, contained in initial part of the file information block. And so, for example: when the version of "EN-US" will have sequence consecutive ASCII codes: 040904E4 in the initial part of the block of information, the corresponding sequence hex values will be: 09 04 E4 04 (at the end in the file information block). Translation of the file to the “Polish” language version entails changing the sequence ASCII values to: 041504E2 - for which the correct hex values sequence will be: 15 04 E2 04 (at the end in the file information block). “English” language version: “Polish” language version: Correcting this way the "NE" file (with the resources previously translated into the desired language using eXeScope program) in the hexadecimal editor – is the unique correcting carried out in a hex-editor. It seems not to affect the correct structure of the file, but enters the correct information about the language of this file. The files: Gdi.exe and Krnl386.exe modified in this way, served me for several weeks, without introducing noticeable errors in functioning of my Windows 98SE system. If there is something wrong with my argumentation above, please correct me. egrabrych

Hmmm ... I had small icons in the Start Menu, I changed it to large icons, even after this change I did restart Windows - but in the key in the registry: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\Component Categories\{00021492-0000-0000-C000-000000000046}\Enum all the time was the same value of the variable Implementing: I went back to small icons - value of variable Implementing remains the same.

No, no... layout.dll is used to restore of the layout of desktop icons. My problem is different: the point is that when several files together are copied to the Desktop, their icons are obligatorily arranged as follows: I would rather have this arrangement:

Where / how Windows 98 saves setting the size of icons in the Start Menu? Not in the Registry or in files: System.ini and Win.ini (if I noticed). Thank you in advance for the information. egrabrych

Is there a way to in order the icons of files being copied together (group) to the Windows XP desktop were deployed not as: but so: Best regards! egrabrych

Maximus-Decim Native USB Drivers does not contain a Usbser.sys I think that between version 3.3 and 3.5 NUSB should not this be the difference.

Indeed, it is!MSCONV97.zip egrabrych

Hi everyone! I made a detailed analysis of versions of files in the SP3.cab. Five files in particular caught my interest: 1) Msconv97.dll - is in version 2003.1100.8165, even though in the SP 3.0 beta 4 it was in version 2003.1100.8166. 2) Mspaint.exe - is in version 5.00.1523.1, so an earlier one than on the installation CD of Windows 98 SE (5.00.1740.1). 3) Msxml.dll - is in version 8.0.6730.0, even though in 2004 Microsoft released the official version 8.00.7002.0 (hotfix KB832414_MSXML2.5_x86.exe, http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=9354). 4-5) Msident.dll - is in version 6.00.2800.1106, Vgx.dll - is in version 6.00.2800.1612, even though in the unofficial update of Internet Explorer 6.0 SP1 - MDIE6CU 3.4 (http://www.mdgx.com/spx/MDIE6CU.EXE) these files are in versions: Msident.dll - 6.00.2800.2000, Vgx.dll - 6.00.2800.1637. Probably it is so for a reason, but what is this reason exactly? Thank you in advance for any information and suggestions on this. egrabrych

Yes, because here the effect was caused by artificially - in order to see whether it is at all possible. This computer with Windows XP, cooperates with your monitor 16:9 and during normal operation this problem is not seen. I apparently just from that it depends.

Unfortunately, yes And not just for "older browsers" and the "incompatible Java"! I conducted the same experiment under Windows XP SP3 with an installed Java SE 1.6.30, for: Firefox 3.6.25, Internet Explorer 8 and Opera 11.60 - with appropriately selected sizes of windows. The result is exactly the same - see the screenshots below: Capture.mht (External link, 1.09MB) It seems that this is simply a "must-be". Permanently helps screen with 16:9 aspect ratio. Thank, CharlesF and mrsk565 egrabrych

Actually I should have asked about it a long time ago. This problem occurs in ALL THE VERSIONS of the Opera known to me, and relates to the multi-page threads of "MSFN Forum". Look carefully at the screenshots I attached: I'm trying to move the arrow pointer over the icon of the site number 66. On the first screenshot, the arrow is still far and all the site icons are displayed in one line. But when the arrow already gets over that icon (the second screenshot), the icon runs out to a new line! Moving the arrow over the site icon number 66 in this new line isn't easy, because it tries to run back to its place in the first line; however it does finally become possible (the third screenshot). Does anyone know anything more about it?

I am your humble servant : copyx.zip Nice to use ... Thank you! Ah, if it was still something of an identical action to "Run Shell Extension for Windows NT" (Runext.dll) with the "Windows NT 4.0 Resource Kit", but running under Windows 9x/ME. "Run with arguments ..." with "Synesis Software Windows Shell Extensions" is not the same ...

@CharlesF: Sorry. I thought that the word "report" at the beginning will be enough understood. But it was not on your side "waste of time" because I found out from you about things that previously I did not know. Thank you egrabrych

Thank you, but with nothing to see here please. This post it was written in reference to the thread http://www.msfn.org/board/topic/154648-dos-format-b-and-label/, which was created in reference to the thread http://www.msfn.org/board/topic/118119-patched-iosys-for-9xme/page__st__100. Oh, such memories from the past. Happy New Year

I’m impressed by your inquisitiveness! I didn’t check the thing you wrote about here, I trust it is just as you say. But I can repay you with something that admittedly didn’t require that much work, but is also an example of how Microsoft caused harm… to itself. http://www.msfn.org/board/topic/154933-send-to-extensions-vs-desktop-create-shortcut-report/#entry986415

(report) As you know, there is an add-on to the Windows called "Microsoft Windows 95 PowerToys". One of the elements of this add-on is called "Send To Extensions". During its installation, the Sendtox.dll file is placed in the %WinDir%\System\ShellExt folder, and in %WinDir%\SendTo folder, there are placed seven shortcuts widening the range of capabilities of the "Send To" command in the context menu. Because the "Send To Extensions PowerToy" works and is useful also in Windows 98, sometimes it is also installed in that operating system. Unfortunately, during the Sendtox.dll file registration, the registry key: [HKLM\Software\CLASSES\CLSID\{9E56BE61-50F-11CF-9A2C-00A0C90A90CE}] gets „intentionally” damaged. Vs.txt The result of these changes is a malfunction of one of the system shortcuts used in the command "Send To": "Desktop (create shortcut)". When used, rather than create a desktop shortcut to the file to which this command has been applied to, it will now open a window of a "new message Microsoft Exchange". The remedy is obviously to restore the key’s proper content [HKLM\Software\CLASSES\CLSID\{9E56BE61-C50F-11CF-9A2C-00A0C90A90CE}], but there wouldn’t have been any problem in the first place, if not for the bug in the Sendtox.dll file. This error, aside from the damage it causes, doesn’t bring any more or less positive effects, and besides, it was possible for the Microsoft to use two different CLSID!

Well, there's a bit of confusion and misunderstanding here. I did NOT report the problem to solve, this problem IS ALREADY SOLVED! The sequence of events was as follows: I was interested in ONLY identification of the type of drive: local disk ("dysk lokalny" - in Polish), CD-ROM disk ("dysk CD-ROM" - in Polish), removable disk ("dysk wymienny" - in Polish) - in Windows 98SE. CORRECTLY drives were identified as follows: the identification below is INCORRECT: My OBSERVATIONS from this experiment are as follows: 1) The file Cdfs.vxd in the version: - 4.90.3000 - original file from Windows ME installation disk - 4.90.3000 - when patched by "CDFS.VXD 4.90.3002 patched with RLoew's" (http://rloew1.no-ip.com/Programs/PTCHCDFS.ZIP) - 4.90.3001 - with hotfix 274175 (http://ftp.isu.edu.tw/pub/CPatch/msupdate/win98se-nsrc/backup/274175usa8.exe) - 4.90.3001 - when patched by "CDFS.VXD 4.90.3002 patched with RLoew's" in Windows 98SE works INCORRECTLY. 2) File Cdfs.vxd in the version: - 4.90.3002 - with unofficial hotfix "IOSYS98.EXE" (http://www.mdgx.com/files/IOSYS98.EXE), PROPERLY also works when you have not installed other files from unofficial hotfix "IOSYS98.EXE". 3) "CDFS.VXD 4.90.3002 patched with RLoew's" can be applied to any version of the Cdfs.vxd file EARLIER than version 4.90.3002 (4.10.1998, 4.10.1999, 4.90.3000, 4.90.3001). In the drawing is bug; should be written: "4.90.3000 - the original file from the Windows ME installation disk" 4) The files Cdfs.vxd: - In version 4.90.3002 - with the unofficial hotfix "IOSYS98.EXE" - obtained when patched by "CDFS.VXD 4.90.3002 patched with RLoew's" Cdfs.vxd file in version 4.90.3001 Are NOT IDENTICAL. For use on Windows 98SE is suitable ONLY: - Cdfs.vxd file in version 4.90.3002 (with the unofficial hotfix "IOSYS98.EXE"), - when patched by "CDFS.VXD 4.90.3002 patched with RLoew's" Cdfs.vxd file in version 4.10.1999 (with hotfix 274175), - the original Cdfs.vxd file in version 4.10.1999 from hotfix 274175 (in version 4.10.1998, as flawed as described in article 274175, omit here). The last of these observations was the reason I wrote that post - because, in my opinion, the conclusion formulated in such a way isn't consequential to the information given in the http://www.mdgx.com/upd98me.php. A thing mitigating this problem is that during the installation of the unofficial patch "IOSYS98.EXE", the existing Cdfs.vxd file is obligatorily converted to the version 4.90.3002. and restoring it to another version is possible only through one's own interference. I described the problem that was already solved in the version 2. of the unofficial patch "IOSYS98.EXE" (which includes changes to the Cdfs.vxd file, introduced by the "CDFS.VXD 4.90.3002 patched with RLoew's"); nevertheless, "returning to the past" on your own is always possible, of which forewarns my note.

Merry Christmas! To All who are present here, and Great Absence.