Petr

You have probably installed my QFE data, right? Belarc Advisor just takes the information from registry, like QFECheck does, and as I wrote as a comment to the QFE.INF, missing files are OK because many files are installed only if they already exist. Petr

Hi, for years I have annoying problems with Invalid Page fault during system startup. They are related to Fineprint and pdfFactory dipatchers. Every 3rd to 5th boot I get the following Invalid Page Fault (it is in Czech but I believe it is no big problem to read it): Datum 11/05/2005 Čas 15:14 Aplikace SPOOL32 způsobila neplatnost stránky v modulu SPOOL32.EXE na adrese 019f:00402015. Registry: EAX=00000004 CS=019f EIP=00402015 EFLGS=00010283 EBX=00000000 SS=01a7 ESP=0086ff84 EBP=00000000 ECX=e53847b0 DS=01a7 ESI=bff7c8bd FS=4157 EDX=bffcd490 ES=01a7 EDI=bff92bc1 GS=0000 Bajty v CS:EIP: ff 33 55 e8 d3 f0 ff ff 89 03 e8 de 0c 00 00 89 Výpis zásobníku: 00000000 00000004 0086ffcc 81a97544 00000008 81a7db2c bff88f20 00000000 81a97544 00000008 81a7db2c 00000007 0086ffa4 0086fdb4 ffffffff bffc0684 Sometimes (every 10th to 20th boot) different IPF error appears: Datum 10/24/2005 Čas 22:44 Aplikace FPDISP5A způsobila neplatnost stránky v modulu FPUI5A.DLL na adrese 019f:2a0197bd. Registry: EAX=00000000 CS=019f EIP=2a0197bd EFLGS=00010216 EBX=ffffffff SS=01a7 ESP=0062f340 EBP=0062f350 ECX=00000000 DS=01a7 ESI=21074d10 FS=36cf EDX=0062f6f0 ES=01a7 EDI=21074d10 GS=0000 Bajty v CS:EIP: ff 50 04 8b e5 5d c2 0c 00 55 8b ec 51 89 4d fc Výpis zásobníku: 0062f6f0 00000000 00000000 00000000 0062f494 2a016245 0062f6f0 00000000 00000000 0062f5e4 2a014ad8 21074d10 21074d10 ffffffff 00000000 7474656c The only way how to continue the work without reboot is to kill both dispatchers by Ctrl-Alt-Del and restart them manually, then eerything is OK. I have reported this problem to the author long time (years) ago but no improvement. I know there are many KB articles like http://support.microsoft.com/kb/q191949/ but I found no help. Does anybody have any idea how to rectify this problem? Is there anybody with the same problem? Petr

Hi, I have one problem with my fully patched Windows 98 SE system, either with the original ASPI, or with Adaptec ASPI 4.60 or with 4.71.2. When any application, like Nero, wants to find the CD burner, the system completely freezes for upto several minutes, mouse is dead, clock is not incrementing seconds, nothing. After that delay everything works well but it is very very annoying. What is my setup: Intel 815EP chipset with ICH2 IDE controller, connected devices: Primary, Master: WDC WD600AB-00CDB0 Primary, Slave: TOSHIBA DVD-ROM SD-M1612 Secondary, Master: PLEXTOR CD-R PX-320A Secondary, Slave: empty CMD/Silicon Image PCI-0649 Ultra-DMA/100 IDE Controller: Tertiary, Master: WDC WD400EB-00CPF0 Tertiary, Slave: empty Quaternary, Master: WDC WD800JB-00CRA1 Quaternary, Slave: empty The problem is related to drives connected to the add-on card, without them everything works quickly. Of course, I have the latest driver for it. Had anybody similar problem? What could I do to improve this terrible behavior of all CD-ROM burning programs? Petr

I supposed something like that. In fact, I never seen any use of .CAT files in Windows 98 SE, is this different in Windows Me? I just looked at some Q310695 fix and the sequence (in the form of .SED file lines) is: AppLaunched=QFEREG.INF PostInstallCmd=310695UP.INF QFEREG.INF contains lines: [DefaultInstall] CopyFiles = Register.cat RunPostSetupCommands = UnprotectMe [SourceDisksNames] 1="CAT File Source","",1 [SourceDisksFiles] WSE22366.cat = 1 [DestinationDirs] Register.Cat = 17,CATALOG; Windir\inf\catalog directory [Register.Cat] WSE22366.cat [UnprotectMe] ;The following command will register the CAT file. Add another entry ;just like it if there are more than one, specifying the next CAT. "%11%\SUCATREG.EXE /D:WSE22366.CAT" So at first tha .CAT file is copied to So at first the catalog file is copied to Windir\inf\catalog directory and then it is registered. And after this, 310695UP.INF copies file to three locations: (unneeded lines removd) [DefaultInstall] CopyFiles=WMeUpd.Copy.qfe,WMeUpd.Copy.Hlp,WMeUpd.Copy.Install,WMeUpd.Copy.Options,WMeUpd.Copy.VMM32 AddReg=WMeUpd.AddReg [DestinationDirs] WMeUpd.Copy.Options=10,options\cabs WMeUpd.Copy.Install=10,options\install WMeUpd.Copy.VMM32 = 22 [WMeUpd.Copy.VMM32] UDF.VXD,,,32 [WMeUpd.Copy.Options] UDF.VXD,,,32 [WMeUpd.Copy.Install] UDF.VXD,,,32 So this is the official way. But what is the meaning of "Options" and "Install" directories? Can we do the same in the servicepack? For all official updates/hotfixes for sure, the procedure would be: 1. To copy all .CAT files from MS fixes 2. To register them by SUCATREG 3. To copy all files as it is done at present, maybe also into "Options" and "Install" directories. The question - how it is with unofficial, patched files? They never have correct .CAT file. I suppose this file has to be signed by Microsoft to be valid. If it is possible to switch SFP off, copy any updated files (with no .CAT files), reboot and switch SFP on, what are these .CAT files meaningful at all? I also suppose that could be possible to switch off the SFP by the installator, or not? I don't have Windows ME experience but I believe there should be a way how to handle everything by the Service Pack installator. Petr

BTW, Microsoft uses often also "Microsoft Windows Millenium Edition" spelling, with one "n" only, especially in the MS Knowledgebase it is confusing. Petr BTW, what is the magic in MS Windows Me hotfixes that they don't require to switch file protection off? I'm not very familar with Windows Me. Petr

It seems to be problem of SYSDM.CPL 4.10.2224 from Q272620 - Negative Hard Disk Free Size Reported on Virtual Memory Tab in System Properties. You may try to use the old one from W98SE CD. BTW, how it is on Windows Me with SYSDM.CPL 4.90.3001? BTW2: in the SYSDM.CPL binary is contained string Hardware\Description\System\CentralProcessor\0 VendorIdentifier Identifier but Regmon shows it is not called. Maybe somebody could chceck why? Petr Please look at this topic. You were quicker than me :-) It is interesting that on ME it shows processor information (see MDGx post in the referenced thread) and on W98 not. Petr

Here is the first beta version for people using Slovak version of Windows 98 SE: http://rapidshare.de/files/8631011/sesp21sk-beta1.exe.html Support forum here: http://www.macich.net/winarna/viewtopic.php?t=393 Petr

You may want to read detail dicussion here: http://www.msfn.org/board/index.php?showtopic=46752 http://www.msfn.org/board/index.php?showtopic=30809 In short: Windows 98 FAT-32 file system can work with partitions larger than 137 GB but Windows Scandisk and Defrag have 137 GB limit. You can use commercial tools like Norton Utilities. The default IDE driver (ESDI_506.PDR without the commercial patch http://members.aol.com/rloew1/Programs/Patch137.htm ) cannot work with IDE disks beyond the 137GB barrier. This is solved by 3rd party drivers, like Intel Application Accelerator for some Intel chipsets. DOS FDISK and FORMAT have cosmetical errors but work correctly with big disks (tested with 200 GB disk). SE SP 2.1 does not change much on this - it just adds http://support.microsoft.com/?kbid=263044 updated FDISK for correct recognizing of HDD bigger than 64 GB. Petr

Hi, few basic questions: I suppose it is not win98, but win98se, right? And with fresh install without SP2.1a it will accept it? Or with older SP2.0.2? When and where this message appears? Do you see any message that file was not found in SP2.CAB? Retrieveing files from SP2.CAB instead of original CD-ROM is intended behavior of preserving mechanism. At first, you should determine if the problem is in SE SP 2.1a or anywhere else. In the specification is 2.2 PCI Slot, older PCs have 2.1 only. Petr

I've noticed that in 2.21 are the following lines for Mitsumi: %VID_03EE&PID_0000.DD%=USBSTOR_CBI, USB\VID_03EE&PID_0000 %VID_03EE&PID_6901.DD%=USBSTOR_CBI, USB\VID_03EE&PID_6901 ;%VID_03EE&PID_6902.DD%=USBSTOR_CBI, USB\VID_03EE&PID_6902 As I already reported here, the driver does not work with Mitsumi Floopy drive with VID_03EE&PID_6901 so I suppose it should be commented out too. Strange thing is that with Windows ME it works perfectly without any driver, and wit Windows 98 SE without nusb and with Mitsumi supplied driver too. I have no idea what is wrong with nusb driver. Petr

You already have the complete list in SPUPDATE.INF file + WBEM updates, Q313829, Q329414, CRL update, root certificates update, MS Installer 2.0, Windows Script 5.6. What you are missing? Or the list like: Q172733, Q180071, Q192425, Q196208, Q212265, Q236926, Q237493, Q239696, Q239887, Q240075, Q240163, Q240308, Q240896, Q241052, Q242004, Q242193, Q242975, Q243320, Q243450, Q243638, Q244357, Q244540, Q245065, Q245272, Q245682, Q246094, Q246387, Q246817, Q249146, Q249635, Q249973, Q250514, Q250876, Q253697, Q253711, Q254660, Q257360, Q257821, Q258680, Q258765, Q259253, Q259728, Q262232, Q263044, Q266772, Q267304, Q268064, Q269239, Q269601, Q269604, Q269874, Q270063, Q271701, Q272621, Q273017, Q273727, Q274113, Q274175, Q274370, Q274548, Q275873, Q277628, Q278033, Q278368, Q280448, Q281533, Q282949, Q283032, Q284837, Q285189, Q285895, Q288430, Q288550, Q289635, Q290831, Q290887, Q291362, Q292539, Q293197, Q293818, Q295629, Q305037, Q306453, Q306889, Q307004, Q308349, Q309081, Q310695, Q311430, Q311561, Q313829, Q314147, Q314941, Q315575, Q317796, Q318307, Q319303, Q319571, Q320798, Q321467, Q323172, Q323455, Q323708, Q327517, Q329414, Q811630, Q813432, Q835732, Q835935, Q870669, Q885836, Q887616, Q888113, Q891711, Q891781, Q892211, Q896358, Q903235, ie55sp2, ie60sp1, rootsupd, scr56, unicows, vcredist would better suits your needs? And regarding IE6.0SP1 - AFAIK there are only few relevat fixes at present: KB896688 - MS05-052: Cumulative security update for Internet Explorer BROWSEUI.DLL 6.0.2800.1692 CDFVIEW.DLL 6.0.2800.1612 DANIM.DLL 6.3.1.147 DXTRANS.DLL 6.3.2800.1520 IEPEERS.DLL 6.0.2800.1497 INSENG.DLL 6.0.2800.1475 MSHTML.DLL 6.0.2800.1523 MSRATING.DLL 6.0.2800.1623 MSTIME.DLL 6.0.2800.1520 PNGFILT.DLL 6.0.2800.1506 SHDOCVW.DLL 6.0.2800.1692 SHLWAPI.DLL 6.0.2800.1740 URLMON.DLL 6.0.2800.1520 WININET.DLL 6.0.2800.1512 and for components related to IE KB833989 - MS04-028: Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution VGX.DLL 6.0.2800.1411 KB903235 - MS05-037: Vulnerability in JView Profiler could allow remote code execution (just adds one killbit to the registry) KB837009 - MS04-013: Cumulative Security Update for Outlook Express DIRECTDB.DLL 6.0.2800.1123 INETCOMM.DLL 6.0.2800.1409 INETRES.DLL 6.0.2800.1123 MSIDENT.DLL 6.0.2800.1123 MSIMN.EXE 6.0.2800.1123 MSOE.DLL 6.0.2800.1409 MSOEACCT.DLL 6.0.2800.1123 MSOERES.DLL 6.0.2800.1123 MSOERT2.DLL 6.0.2800.1123 OEIMPORT.DLL 6.0.2800.1123 OEMIG50.EXE 6.0.2800.1123 OEMIGLIB.DLL 6.0.2800.1123 OEUNINST.EXE 6.0.2800.1223 OEUPDATE.EXE 6.0.2800.1276 WAB.EXE 6.0.2800.1123 WAB32.DLL 6.0.2800.1409 WABFIND.DLL 6.0.2800.1123 WABIMP.DLL 6.0.2800.1123 WABMIG.EXE 6.0.2800.1123 and maybe also KB891781 - MS05-013: Vulnerability in the DHTML editing component ActiveX control could allow code execution DHTMLED.OCX 6.1.0.9231 Are there any other relevant fixes that should be applied? Petr

But as was also noted, it is questionable what build is newer and what build is older. If you compare 5.2.3790.2453 (srv03_sp1_qfe.050525-1536 and 5.2.3790.309 (srv03_gdr.050413-1540) you see that the date 050525 is newer than 050413 but build number 1536 is lower than 1540. And of course one build is qfe and the second gdr. My opinion is that it is better to believe Microsoft that for Windows 98 is intended 5.2.3790.309 (srv03_gdr.050413-1540). Has anybody noticed any difference in behavior or functionality? Petr

Just in case this forum is read by some people from Czech Republic - beta version is here: http://www.winpack.org/nsp_petr/sesp21cs-beta4.exe and Czech discussion forum is here http://www.macich.net/winarna/viewforum.php?f=27 Petr

Just tip for cleaning up the code () The following lines have exactly the same result in [AddReg.Something] sections of INF files: HKLM,TestKey,TestValue,0x00010001,0x00000400 HKLM,TestKey,TestValue,0x00010001,0x400 HKLM,TestKey,TestValue,0x00010001,00,04,00,00 HKLM,TestKey,TestValue,0x00010001,1024 HKLM,TestKey,TestValue,0x00010001,00001024 HKLM,TestKey,TestValue,0x10001,0x00000400 HKLM,TestKey,TestValue,0x10001,0x400 HKLM,TestKey,TestValue,0x10001,00,04,00,00 HKLM,TestKey,TestValue,0x10001,1024 HKLM,TestKey,TestValue,0x10001,00001024 HKLM,TestKey,TestValue,0x10001,"0x00000400" HKLM,TestKey,TestValue,0x10001,"0x400" HKLM,TestKey,TestValue,0x10001,"00,04,00,00" HKLM,TestKey,TestValue,0x10001,"1024" HKLM,TestKey,TestValue,0x10001,"00001024" HKLM,TestKey,TestValue,"0x10001","0x00000400" HKLM,TestKey,TestValue,"0x10001","0x400" HKLM,TestKey,TestValue,"0x10001","00,04,00,00" HKLM,TestKey,TestValue,"0x10001","1024" HKLM,TestKey,TestValue,"0x10001","00001024" HKLM,TestKey,TestValue,65537,0x00000400 HKLM,TestKey,TestValue,65537,0x400 HKLM,TestKey,TestValue,65537,00,04,00,00 HKLM,TestKey,TestValue,65537,1024 HKLM,TestKey,TestValue,65537,00001024 I have read (not tested) that for Windows 95 is the correct syntax only: HKLM,TestKey,TestValue,65537,00,04,00,00 In SPUPDATE.INF are combined various syntaxes. Petr

sesp21en contains: HHCTRLUI.DLL 5.2.3635.0 HHCTRL.OCX 5.2.3790.309 (srv03_gdr.050413-1540) HHSETUP.DLL 5.2.3790.309 (srv03_gdr.050413-1540) HH.EXE 5.2.3790.309 (srv03_gdr.050413-1540) ITIRCL.DLL 5.2.3790.309 (srv03_gdr.050413-1540) ITSS.DLL 5.2.3790.309 (srv03_gdr.050413-1540) sesp21fr contains: HHCTRLUI.DLL 4.74.9273 HHCTRL.OCX 5.2.3790.309 (srv03_gdr.050413-1540) HHSETUP.DLL 5.2.3790.309 (srv03_gdr.050413-1540) HH.EXE 5.2.3790.309 (srv03_gdr.050413-1540) ITIRCL.DLL 5.2.3790.309 (srv03_gdr.050413-1540) ITSS.DLL 5.2.3790.309 (srv03_gdr.050413-1540) sesp21de contains: hhctrlui.dll 5.2.3664.0 hhctrl.ocx 5.2.3790.2453 (srv03_sp1_qfe.050525-1536) hhsetup.dll 5.2.3790.2453 (srv03_sp1_qfe.050525-1536) hh.exe 5.2.3790.2453 (srv03_sp1_qfe.050525-1536) ITIRCL.DLL 5.2.3790.2453 (srv03_sp1_qfe.050525-1536) ITSS.DLL 5.2.3790.2453 (srv03_sp1_qfe.050525-1536) None SE SP 2.1 contains 5.2.3790.1830 (srv03_sp1_rtm.050324-1447). Petr

I've created simple package for checking file versions by QFECheck tool: http://www.winpack.org/nsp_petr/sesp21en-qfe.exe It installs QFECheck.exe, QFECheck.hlp and it copies QFE.INF into %windir%\INF folder. Missing files are OK (some are installed only if the file already exists), wrong version is OK just in case of WBEM files if WBEM 1.5 is not installed. It can be uninstalled by Add/Remove programs, QFECheck.exe, QFECheck.hlp are kept in the system, just the registry information and QFE.INF file are deleted. It is intended as tool for those who want to verify that everything was installed as expected. Petr

Very small correction: [Copy.Sysbckup] Configmg.vxd ;239887 should be 253711. Petr

For dll files (generally all 32-bit PE executables) I'd recommend Restorator 2005. The procedure is very simple, you can just extract and then import all resources at once and then just copy (and possibly edit) Version resource. As for 16-bit NE files, the worse was GDI.EXE, fortunately USER.EXE and SYSDM.CPL I was able to receive localized from Microsoft. Unfortunately after manual translation. :-) 16-bit LE executables (.VXD and .386) needs some manual work but it's not big problem again. All texts are stored in 64 KB blocks (1000 hex), the easiest way how to find these blocks is to compare original English file with original file in your language. Almost all files contain one text block only, just NWREDIR.VXD and vpicd.vxd contain 2 blocks and VMM.VXD contains 3 blocks. Then you will find the same block in new updated English file and replace it by the block from file in your language. Then it is necessary to modify some bytes: 00015C: length of the first text block (just copy from the file in your language) 00017C: length of the second text block (just copy from the file in your language) 00019C: length of the third text block (just copy from the file in your language) Then it is posible (not necessary) to modify the language code and character set in Version resource. It is there twice: 1. after StringFileInfo it is in text format, e.g. 040904E4 means US English (0409) and ANSI Latin 1 character set (04E4 in hex = 1252 in dec) 2. After Translation (usually last 4 bytes of the file) is the same information in binary. Address 000138 shows start of the resource but it is usually at the end of the file. Text blocks for VMM.VXD has to be extracted from VMM32.VXD. Is this description sufficient? I hope I forgot nothing. I personally think that it would be much easier to write simple tool than to learn hack files 15 people from 15 different countries. Petr

I've found the source of the problem - DSOUND.DLL is also in SYSBCKUP folder. Petr Edit: No, it is strange, although the file is not installed by SESP21 into SYSBCKUP folder, it is there! Interesting. Petr

I have changed: 6. Add files with local resources: JSxx.DLL, SCOxx.DLL, SCRRNxx.DLL, VBSxx.DLL to SP2 folder and WSHxx.DLL to SUPP folder and edit SCR56.INF. JSxx.DLL, SCOxx.DLL, SCRRNxx.DLL, VBSxx.DLL does exist on Windows 98 SE CD-ROM, but WSHxx.DLL not. Petr

DSOUND.DLL from Q269604 is multi-language file, it contains resources in the following languages: English, Czech, Simplified Chinese, Traditional Chinese, French, Dutch, Italian, Japanese, Korean German, Polish, Portuguese (Brazilian), Russian, Spanish (Mexico), Spanish (international), Spanish (traditional), Swedish. Petr

As a maintainer of Czech version of Unofficial Service Pack for Windows 98 SE (and FE) I found that it is really not easy to localize all updates and hotfixes. It took long time to localize everything (with exception of TWEAKUI.HLP). Even though there are French, German, Dutch, Polish and Italian localizations of SESP, there are still many files not localized. No surprise, it eats much time. There are several groups of international versions of Windows 98. They are shortly described in Appendix A - International Windows 98 of Microsoft Windows 98 Resource Kit. The most interesting thing is that the so called "United States" release version is available in English, German, Italian, Norwegian, Swedish, Dutch, French, Spanish, Portuguese (Prtugal), Portuguese (Brazil), Danish, Finnish, Russian, Polish, Hungarian, Greek, Turkish, Slovak, Slovenian languages. In total 20 versions with the same code. I've got an idea that it would be extremely useful to have a tool (or set of tools) for automated translation to other language. This tool would just took 3 files (or folders) as input: - English original version - Original version in new language - English version of the update Then the tool would compare resources in English original and updated file and for identical resources it would replace them in newly created localized file by localized version of the same resources. Resources that has changed un the update would be leaved untouched for manual editing. As I already described in the Localization of SP 2.0 topic, there are 4 basic types of binary files to localize: 1. 32-bit PE files (most executables) 2. 16-bit NE files (user.exe, gdi.exe, sysdm.cpl, wdmaud.drv, compobj.dll, netdi.dll, unimdm.tsp) 3. 16-bit LE files (.VXD, .386) 4. Other executables - KEYB.COM, IO.SYS (WINBOOT.SYS) For all of these files I have better or worse knowledge where and how the resources are stored. For PE, NE and LE files it would be also nice (but not necessary) to translate (the same way) FileDescription and ProductName in the Version resource to get exactly the same localized file as from Microsoft. The only problem would be help files. This is not the case of SESP. There are HARDWARE.HLP (Q242975 already available in all languages), TSHOOT98.CHM (Q239887 already available in all languages), WSCRIPT.HLP (scr56xx already available in all languages) and TWEAKUI.HLP (English only) So the full localization of all files installed on the system would mean just running this tool and manual editing of few exceptions. The result would be service pack with all localized files with exception of the user interface. This is not necessary but it would not big problem to ask somebody to translate the LICENSE.TXT, INFEX.INI and few strings in INF files. The biggest problem is that I'm not coder - so I'm not able to write this tool. Is there anybody who could write it? I can help with file formats and with testing. The result would be not only high quality fully localized SESP in 20 languages, but also FESP, MESP and it could be used even for any other update not available in the specific language. I already have extracted all langage versions of files in SESP from intallation CD-ROMs and here are the tables. I'm sorry - they are very big (600 KB) but I don't know how to export them from Excel other way. Windows 98 SE files in various OS language versions Availability of localized fixes I did not too extensive search so maybe many other localized fixes are available but still is clearly visible that there are too many files to localize. Any suggestions? Petr

I haven't gotten those files from any of those OSes. They all came bundled with one software installer or another and got written in the system directory. I actually install quite a lot of software so I can't remember which ones. Maybe, but the versions of RICHED32.DLL you have mentioned are from the folowing OSes: 4.0.410.59 is part of Windows 95 Gold and OSR2 4.0.834.839 is part of Windows 98 and Windows 98 SE 4.0.835.1374 is part of Windows NT 4.0 4.0.993.4 is part of Visual Studio 6.0 5.0.1461.82 is part of Q249973 5.0.1461.82 is part of Windows Millennium 5.0.2008.1 is part of Windows 2000 Beta 3 5.0.2134.1 is part of Windows 2000 5.1.2600.0 (xpclient.010817-1148) is part of Windows XP 5.2.3790.0 (srv03_rtm.030324-2048) is part of Windows Server 2003 Only 5.0.1461.82 (part of Q249973) seems to be freely available. Petr

I see now. But they will be installed by default Internet Explorer setup anyway. Petr

OK, so the origin is Form Windows Server 2003 SP1: RICHED20.DLL 5.31.23.1224 Rich Text Edit Control, v3.1, Microsoft RichEdit Control, version 3.1 USP10.DLL 1.422.3790.1830 Uniscribe Unicode script processor From Windows Me: RICHED.DLL 4.0.834.839 Windows 95 Rich Text Edit Control, Microsoft® Windows Operating System 4.0 RICHED32.DLL 5.0.1461.82 Windows 95 Rich Text Edit Control, Microsoft Exchange 5.0 Service Pack 4 From Microsoft Visual Studio 6.0 Service Pack 6: RICHTX32.OCX 6.1.97.82 RICHTX32.OCX is not present in Windows 98 SE nor in Windows Me - do you know what programs use it? Both Windows 98 Gold and Windows 98 SE contains binary identical file: RICHED.DLL 4.0.834.839 so it is not needed for these OSes. SESP 2.1 contains exactly the same version: RICHED32.DLL 5.0.1461.82 Windows 95 Rich Text Edit Control, Microsoft Exchange 5.0 Service Pack 4 that comes from Q249973. But the file size differs: RICHED32.DLL from WindowsMe: 212992 bytes, internal date 06/09/2000 02:35:49 RICHED32.DLL from Q249973: 203024 bytes, internal date 12/13/1999 21:04:55 Anyway, in WinME it already exist and for Win98 the Q249973 version should be OK. So the result is that for Windows 98 Service Pack just the following files are necessary: RICHED20.DLL 5.31.23.1224 USP10.DLL 1.422.3790.1830 RICHED32.DLL 5.0.1461.82 and for Windows Millennium Service Pack just: RICHED20.DLL 5.31.23.1224 USP10.DLL 1.422.3790.1830 Right? Petr Maybe the reason is that none of these files is available in any Service Pack or update. This file only can be bought with Windows NT 4.0 or Windows 2000 or Windows XP or Windows Server 2003. Petr