Petr

Quick trick how to install Adobe Reader 6.x on Windows 98 FE: 1. Replace kernel32.dll with version 4.10.2225 from Windows 98 SE 2. Install Adobe Reader 6.x 3. Replace kernel32.dll back the FE version. Tested several times with no problem. I really don't understand why the installer has this restriction. On Windows XP is AR7 much quicker than AR6 so I'd like to see AR7 on 98SE. Petr

All developer related thing are here: http://www.mozilla.org/developer/ Petr

And what about to use extract with "/A"? /A Process ALL cabinets. Follows cabinet chain starting in first cabinet mentioned. It means if you want to extract explorer.exe, you will just write (based on your example): EXTRACT /A D:\WIN98\BASE2.CAB EXPLORER.EXE Another possibility is to use Total Commander, Alt-F7 (Search), and check "Search archives". Petr

Maybe it is no problem in English version at all, maybe just minor. Petr I tested MetaPad v3.51 and using v5.3x of riched20.dll file on my WinME machine. worked ok. just be sure you have updated most of the font files on your computer. The problem is on Windows with "non-english" character set, it means codepage 1250 for example. I suppose you have Windows with "english" codepage 1252. Petr

Yet more misinformation... I agree, this article is full of misinformation. Petr

Please see this post in this thread: http://www.msfn.org/board/index.php?s=&sho...ndpost&p=407390 Petr

Why? Petr

It is much quicker, supports pdf 1.6 format and from my point of view it has better search. Petr That's nice. Is there any easy way how to arrange everything? Petr

Have you found any problem with riched20.dll 5.4 and Office 97 & 2000? I have on my system with Office 2000 and no problem so far. Metapad 3.51 cannot be used without version 5.4 on some Windows versions. I cite form http://www.liquidninja.com/metapad/faq.html#Q18 Maybe it is no problem in English version at all, maybe just minor. Petr

Here is the latest file I have: http://old.winpack.org/nsp_petr/fesp201en-alpha1.exe Petr

OK, it seems I have not expressed clearly enough. SHWLAPI.DLL from IE 6.0 SP1, all versions from 6.00.2800.1106 to 6.00.2800.1740, have four unresolved dependencies to delay-loaded modules: APPHELP.DLL (file missing), USERENV.DLL (file missing), OLE32.DLL (CoWaitForMultipleHandles function missing), SHELL32.DLL (SHBindToParent function missing) So although Dependency Walker shows them, IE 6.0 SP1 has no problem with them and other applications too. Therefore I guessed it might be possible that delay-load dependency to mso.dll in riched20.dll version 5.40.11.2212 will cause no problem too. Latest SHLWAPI.DLL for IE5.5 SP2 seems to be 5.50.4957.200 and has no unresolved dependencies. Petr

Yes, these characters don't exist in 1252 codepage used in English, Brazilian, Danish, Dutch, Finnish, French, German, Italian, Norwegian, Portuguese, Spanish and Swedish versions of Windows 98. 1250 codepage is used in Czech, Hungarian, Polish, Slovak and Slovenian versions of Windows 98. 1251 codepage is used in Russian version. 1253 codepage is used in Greek version. 1254 codepage is used in Turkish version. 1255 codepage is used in Hebrew version. 1256 codepage is used in Arabic version. Apparently the probems with font switching do not occur with riched20.dll version 5.30 and 5.31 on systems with 1252 codepage. They occur in systems with 1250 codepage and riched20.dll version 5.40.11.2212 sems to be the only one that works correctly. I have not tested any other Windows version although I have them in my MSDN library, maybe some time. Petr

Now I'm not sure what do you mean. SHLWAPI.DLL was just an example of a DLL with unresolved delay-load dependencies, officialy made by Microsoft for Windows 98. I expressed my hope that also RICHED20.DLL with unresolved delay-load dependency could work. Petr

Do you mean that all those files are in the 98SE uSP currently ? I mean SHLWAPI.DLL that is a part of the April 2006 Security update IE6.0sp1-KB912812-Windows-98-ME-x86-ENU.exe. uSP is not resolving these dependencies. Petr

The table is the same as the old one but maybe the character set was translated by the browser. I wanted to have table with more characters per code to see if the font has changed or not. The dependency to mso.dll is delay-load, maybe it is never used?. Yes, I already mentioned that it is from Office XP SP3. Current SHLWAPI.DLL 6.00.2800.1740 (xpsp2.050831-1533) has also unresolved dependency to delay-loaded modules APPHELP.DLL (file missing), USERENV.DLL (file missing), OLE32.DLL (CoWaitForMultipleHandles missing), SHELL32.DLL (SHBindToParent missing) and everything seems to be OK. Petr

I've looked into the Award 6.00PG BIOS how it was done in 1999, here are fragments of the code: ;Note : This chipset support Sub-system ID & vendor ID programming ; The BIOS will copy "Vendor ID" & "System ID" to these two fields. ; If customer need specific subsystem ID, please add following switch: ; SUBSYSTEM_VENDOR_ID EQU 0xxxxH;for subsystem vendor ID ; SUBSYSTEM_ID EQU 0yyyyH;for subsystem ID ; ;Program Subsystem Vendor ID & subsystem ID xor bh, bh ;bus 0 mov ax, SUBSYSTEM_VENDOR_ID;sub-vendor ID for manufacture mov cx,(TSC_ID SHL 8)+2CH F000_call ASet_CfgSpace_Word ;program subsystem vendor ID mov ax, SUBSYSTEM_ID ;sub-system ID for manufacture mov cx,(TSC_ID SHL 8)+2EH F000_call ASet_CfgSpace_Word ;program subsystem vendor ID This is just an example. Petr

Apparently just some motherboards are supported, with the following Subystem IDs: 147B 1800 ABIT Computer Corp. 147B 1801 ABIT Computer Corp. 1558 0400 CLEVO/KAPOK Computer 1558 0401 CLEVO/KAPOK Computer 1558 2263 CLEVO/KAPOK Computer 1458 5004 Giga-byte Technology 1462 5332 Micro-Star International Co., Ltd. 1462 5470 Micro-Star International Co., Ltd. 1462 5642 Micro-Star International Co., Ltd. 1462 7001 Micro-Star International Co., Ltd. 1462 7010 Micro-Star International Co., Ltd. 144D B01C Samsung Electronics Co Ltd The subsystem ID is one time programmabe by BIOS during the boot process, it is possible to change it by modifying the BIOS but I never tried this. Petr

I'm still not sure why on your screenshots are displayed characters from 1250 codepage but some of them witout accents. Maybe because your browser has changed the encoding? I have packed the file into zip archive: table2.zip, please let me know if your screenshots are still the same. Anyway, it looks like 5.40.11.2212 versions has no display problems on all systems, now it is necessary to know if it works well with all possible applications. Petr

BTW, I see differenet characters (CP1252) on Windows 98 English: Code Pages Supported by Windows: Windows Code Pages OEM Code Pages ISO Code Pages Petr

Now I tried the same test on Windows 98 English and I have the same result as you - i.e. no problems. Character 173 (soft hyphen) is displayed just with riched20.dll version 5.0.153.0, not with any newer version. Codepage 1250 is native to some Windows 9x language versions, it cannot be changed because all system dialogs would become corrupted. Here: http://www.microsoft.com/globaldev/referen...sion.mspx#win98 you can find which language version has which ANSI and OEM codepage. (ANSI codepage is used in Windows and OEM codepage is used in DOS). Petr

So this is my test result - very briefly: I have prepared simple table with all characters with 8th bit set, i.e. code 80 to FF in hex, or 128 to 255 in dec. They can be manually enterd as ALT+0128 to ALT+0255. The table can be downloaded here. In Notepad, with default fixedsys font in 1250 codepage, everything is correct because it does not use riched20.dll: In Metapad, with default fixedsys font in 1250 codepage and riched20.dll any version from 5.30.23.1200 to 5.31.23.1224, the display is broken significantly and at least 4 different fonts appear: With riched20.dll 5.40.11.2212 (from Office XP SP3) everything look good, with exception of character AD (173), soft hyphen, that is not displayed at all. Maybe it is by design. Surprisingly, riched20.dll version 5.50.99.2012 (from Office 2003) has the problem of 5.3x versions corrected only partially, just accented letters display correctly, but other signs (with code 132, 134, 135, 137, 149, 150, 151, 155, 161, 162, 178, 189, 255) change the font again. I tried to set font to Courier - Western script and there are also font changes visible: [Edit: it seems Metapad is too clever and always uses 1250 codepage (Central European) for displaying, even if 1252 (Western) is set. So I have renmoved the screenshot] So if there will be no incompatibility with other applications, the best choice would be version 5.40.11.2212. Petr

"č" is E8 (0232) in codepage 1250 "ě" is EC (0236) in codepage 1250 See also http://www.microsoft.com/typography/unicode/1250.gif I will do some additional tests and let you know. Petr

Hello MDGx, do you remember what applications have problems with riched20.dll 5.40 (from Office XP) or 5.50 (from Office 2003)? Petr

Thak you for reminding me that we already discussed this topic. Version 5.31.23.1224 has the same problem as all known 5.30.x.x versions. In short, "ě" and "č" letters (maybe more) cause switching to different font for all 5.3x.x.x versions so the problem I'm trying to rectify is specific to some languages only. But the possible incomaptibility of 5.40 and 5.50 versions would be the same in all language versions I suppose. I forgot to mention that riched20.dll is language independent so it could be tested in any language Windows version. Petr

Some time ago I wrote here that Metapad has big problems with international characters because of problems in riched20.dll. Now I have found that the same problems (not only in Metapad) can be solved on Windows XP by using newer versions of riched20.dll. These new versions have some unresolved dependencies in delay-loaded modules but I'm not sure if it is real problem - my short tests found none. I have prepared package riched20.zip that contains four different versions of riched20.dll 5.30.23.1221 - Windows XP SP2 (this one is present in the uSP 2.1a) 5.30.23.1226 - Windows XP SP2 KB896430 5.40.11.2212 - Office XP SP3 5.50.99.2012 - Office 2003 KB900459 Please test the newer versions (5.40 and 5.50) if they break anything. Or maybe anybody already did these tests? In case of success I'd suggest to add the highest functional version into the next uSP. Petr