Joseph_sw

thats right, i just copied any "flash*10K*" files from networked winxp into my win98se. i never liked how adobe installer doing strange checks just to extract & registering an activeX control ..., but i find it amusing how adobe flash installer trying to beat KEX each time win9x user (with KEX help of course) able to install previous version of flash10.

for the ActiveX version, try registering the Flash10K.OCX using RegSvr32.exe that method works for me since Kex 4.5 RC1, and it remain so on RC4. Version Information on http://www.adobe.com/software/flash/about/ now said: You have version 10,1,85,3 installed

Great. I tried your suggestion, using Dependency Walker profiling, it works for me too! (both MameUI32 and MamePP) Now i can play that arcade emulator again with KernelEx RC4 installed. How did Dependency Walker able to bypass that error?

Thats faulty of XP' Local Security Settings. Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> Security Options Look something like "Network access: " that has disable/enable settings fiddling with them could resolve it. (Usualy this: Network access: Do not allow annoymous enumeration of SAM accounts and shares. in my settings i change it to: Disabled, counter intuitive with double negative.) However, i also recomend to DISABLE "Remote Registry", in Control Panel -> Administrative Tools -> Services Before i disable that services, i've discover that other connected XP machine interfering with registry that revert my custom XP local security setings to their unconfortable 'default' settings. Some malicious malware also exploit that services too. Remote Registy .., i glad win9x doesn't have this stupidity.

i use the Mame Official Windows Binary Packages release from: http://mamedev.org/release.html It also have link for source code, and link for a few roms test (just copy/move the downloaded rom in .zip form to roms directory). To clarify per MSFN rule, respective Owner of that roms, gives their explicit permision for MameDev to host their roms images there. i already try the "Disable Custom Heap" option as well any others in KernelEx compatibility settings tabs, none of it solve the Mame problem on RC1 / RC3 release, i got the same result. To replicate the error simply try to run the MAMEPP.EXE Should nothing goes wrong, Mame should give the list of random selection of available roms from roms directory. However with RC1/RC3 i got ta Message saying "Out of Memory!", then exit the Mame.

i lucky enough to grab the Kex 4.5 RC3 before it got withdrawed. i installed on my system {English 98SE, with 98SE2ME + NUSB 3.3 + RP 9.6.6} so far i haven't encountered any problem with it. The RC3 still have the same behaviour as RC1 thats makes MAME spiting "Out of Memory!" exception error, regarless compatibly settings. Downgrade to beta2 make MAME works, but obviously flash10 is not working with beta2, so i keep the RC3 instead.

KEX-4.5-RC1 is cool, regsvr32 now works properly for many .ocx/.dll, for example: 'regsvr32 flash10h.ocx' now just simply works. however, this release also raises (std::bad_alloc &) exception error, that makes M.A.M.E decided to terminate its process. Mame source-code: http://mamedev.org/release.html i'm using MemeUI32 which is a Mame front-end that integrated with the main mame core: http://www.mameui.info/ the exception error doesn't happen if i fall back to KEX-4.5-Beta2. codes from mame's machine.c ... catch (std::bad_alloc &) { mame_printf_error("Out of memory!\n"); error = MAMERR_FATALERROR; } ...Mame gives me "Out of memory!" messages box error when i tried to run the roms, with Kex 4.5 RC1.

in one win98SE machine, i can't use any usb flash disk, it just gives usual blue-screen Exception Error 0E xxxx:xxxxxx IOS (4) vxd stuff. however, after checking bootlog.txt content i found suspicious entry: [0015EE7A] Dynamic load failed C:\WINDOWS\system\IOSUBSYS\intelvsd.vxd : [0015EE7A] Not a valid device - possibly corrupt after removing that file from IOSUBSYS directory (renaming it into antyhing_else.vxd, wont work), NUSB is now fully functional in that machine. minimum API requirement checking can be done using wdmcheck under win9x system.

i having trouble when i tried to select some texts by click-drag on this forum, this forum get un-responsive for couples seconds to a few minutes, happen only on new forum though, never happen before the upgrade. so, my temporary workaround is to add www.msfn.org into restricted sites zone. sure i lost many functionality what the new forum offer, but it makes this forum more browseable.

well, the unicode.bin that i have was exactly came from the win98_22.cab file.i also have my winME installer ready, unicode.bin from win_8.cab which also binary exact match with the win98se (win98_22.cab) counter part. this the listing codepages found in that unicode.bin 1 - 437 - 0034C 0022C 1 - 00578 0027D 12 2 - 850 - 007F5 0022C 1 - 00A21 001D9 6 3 - 1252 - 00BFA 0022C 1 - 00E26 001AA 10 4 - 1250 - 00FD0 0022C 1 - 011FC 008C4 137 5 - 1251 - 01AC0 0022C 1 - 01CEC 00643 88 6 - 1253 - 0232F 0022C 1 - 0255B 006B5 99 7 - 1254 - 02C10 0022C 1 - 02E3C 008A1 134 8 - 1257 - 036DD 0022C 1 - 03909 00395 55 9 - 737 - 03C9E 0022C 1 - 03ECA 003C1 56 10 - 852 - 0428B 0022C 1 - 044B7 00881 132 11 - 855 - 04D38 0022C 1 - 04F64 0061B 85 12 - 857 - 0557F 0022C 1 - 057AB 00890 133 13 - 866 - 0603B 0022C 1 - 06267 0061C 85 14 - 869 - 06883 0022C 1 - 06AAF 0064E 92 15 - 775 - 070FD 0022C 1 - 07329 00243 5 16 - 874 - 0756C 0022C 1 - 07798 00191 12 17 - 1258 - 07929 0022C 1 - 07B55 002E1 40 18 - 860 - 07E36 0022C 1 - 08062 0093C 144 19 - 861 - 0899E 0022C 1 - 08BCA 0093C 144 20 - 863 - 09506 0022C 1 - 09732 0093C 144 21 - 865 - 0A06E 0022C 1 - 0A29A 0093C 144 22 - 1255 - 0ABD6 0022C 1 - 0AE02 0023A 26 23 - 862 - 0B03C 0022C 1 - 0B268 009FA 160 24 - 1256 - 0BC62 0022C 1 - 0BE8E 0031F 44 25 - 708 - 0C1AD 0022C 1 - 0C3D9 001F0 9 26 - 710 - 0C5C9 0022C 1 - 0C7F5 00245 20 27 - 711 - 0CA3A 0022C 1 - 0CC66 001F9 14 28 - 720 - 0CE5F 0022C 1 - 0D08B 0020B 12 29 - 786 - 0D296 0022C 1 - 0D4C2 001F3 13 30 - 864 - 0D6B5 0022C 1 - 0D8E1 00218 14 listed in order of appearances in original unicode.bin that i have Code page - Offset Length Ranges (cp to uni) - Offset Length Ranges (uni to cp) i suspect that localized version of win9x might have different content of unicode.bin going on. ack, its make me want to hunt for that files.

oh sorry, i have been busy trying to port that java into Delphi as that remaining programing language that were still installed on my computer, i lost my java se installer somehow. i probably gonna need the unicode.bin result from that java program, just to compare wether my port attempt were done correctly or not. currently i just finished porting the CodePage class, so i haven't tried how the new unicode.bin will works on the system. question: 1. is there any limit in maximum size unicode.bin? i intend to add all codepage for every existing cp_###.nls in my computer. original unicode.bin were only contain 30 codepages, you example was 9 codepages, in my system theres 36 cp_####.nls files. 2. in prgram given it seem you deliberately skip cp.addMapSingle() for cp 0x81, 0x8D, 0x8F, 0x90, 0x9D, for cp1252 why is that? that were incidentaly chracters that can't be used as filenames in cp_1252. the differences between cp_1252.nls and cp-1252 in original unicode.bin was 0x8E & 0x9E which also can't be used in filenames. anyway that java code were very informative , thanks to that i now know about how unicode.bin should be read/inspected. while unicode.bin contain 30 cps, i look in win98se .cab files, it only provided 20 cp_####.nls files, hmm...

i'm definetely interested about modifiying the unicode.bin myself, as i still have grudge on CP-1252 about ansi/ascii character that can't be used as filenames.now, where do i start? what i need to know about unicode.bin' data structures?

is theres also posibilty that conversion were done by kernel32.dll itself (somewhat semi hard-coded) ? as in the kernel32.dll file also contain some data structure of those cp_####.nls files the 8->16 CodePage to UTF16, and 16->16 UTF16 to CodePage data structures (using to those three-layered lookup table) thanks to your earlier post about the .nls files, i found that fact in kernel32.dll

i also have similar devices (its Huawei E220 HSDPA USB modem), but ... yeah the driver is wdm compliant, however it still have missing imports, wdmcheck told me so. i notice that missing imports were provided by winxp system services. (such as smartcard discovery, etc...) until i found a way to provide it to drivers (perhaps thru emulation layer), or better yet, find a win9x compatible drivers, that devices won't be usable in win9x. --- sidestory: its kinda ironic, that because wdmcheck i finaly figured out why that device works on some winxp system, but not on others xp system. those system have their some of needed system services disabled, most likely due to efficiency reasons. nowhere in manual, nor in program provided, stated that such system service must be enabled in order for the device to works properly.

i guess i'm not the only one who also disable hardware acceleration settings in flash. however, my story was quite diferent, i found that in my system, with that setting on, when the flash tried to swicth to full-screen mode, its shows grabled display instead. (only some .swf behaves like that though) gfx: ATI Radeon 9250

I'm also curious whether IO.SYS really observes that bootsector setting, or simply 'ignores' it.

i just found another information that might be the true cause why win98SE (english) refuse to do any file operations, with such character. i found data structures that very similar in those cp_####.nls in KERNEL32.DLL. that structure is CodePage_to_UTF (100h words lookup) followed by UTF_to_CodePage data (this even using the same 3-layered lookup), after checking i also found conversion from CodePage to UTF back to CodePage from that data in kernel32.dll, doesn't match for following CodePage indices: 80, 81, 8D, 8E, 8F, 90, 9D, 9E with exception for 80, the rest were characters that can not be used in filenames! (in ACP 1252) UTF_to_CodePage data was 2F0 words in size. i intend to patch that data to prove the suspicion, however, i not quite sure how to do that other than manual hex editing, and i still having trouble forming/forging a proper UTF_to_CodePage table that will fit the size restriction. edit: i 'll try to fix the 81 & 8F 8E & 9E, i'll inform the result UPDATE: that also turn to be failed too, i still can't use that characters in filename.

a fews days ago i decided to download the latest known directX redist (Aug 2009) download link: http://www.microsoft.com/downloads/details...b1-442d8712d553 after installing it on other winxp, a thought to see if it would still exhibit the same type of error as previous redist on win98se, occured to me. i followed the thought and proceed to install it on my win98SE system, and to my surprise it said "Installation Complete" ! couldn't believe my eyes, then as confirmation i look for DirectX.log file, it also have this following lines: 11/16/09 13:32:13: DXSetup: No command line switch 11/16/09 13:32:13: DXSetup: StartWizard() 11/16/09 13:32:14: dsetup32: IsWow64(): Windows 2000 or Windows 9x. 11/16/09 13:32:16: DXSetup: CDXWSetup() 11/16/09 13:32:17: DXSetup: start installation 11/16/09 13:32:17: DSETUP: DirectXSetupA(): hWnd: 00000554 dwFlags: 02010098 11/16/09 13:32:17: dsetup32: === SetupForDirectX() start === 11/16/09 13:32:17: dsetup32: Sep 4 2009 17:32:16 11/16/09 13:32:17: dsetup32: DXSetupCommand = 0. 11/16/09 13:32:17: DXSetup: DSetupCallback(): Phase = 0, Steps = 0 11/16/09 13:32:17: dsetup32: DirectXSetupIsJapanese == 0 11/16/09 13:32:17: dsetup32: DirectXSetupIsJapanNec == 0 11/16/09 13:32:17: dsetup32: Installing on Win98 11/16/09 13:32:17: dsetup32: IsWow64(): Windows 2000 or Windows 9x. 11/16/09 13:32:18: dsetup32: CLR version number = 2.0.50727 11/16/09 13:32:18: dsetup32: Checking the version: HKLM\software\microsoft\directx\Version 11/16/09 13:32:18: dsetup32: Version in registry = 4.09.00.0904 11/16/09 13:32:18: dsetup32: Version in DLL = 4.09.00.0904 11/16/09 13:32:18: dsetup32: RC in registry = 00, RC in DLL = 00 11/16/09 13:32:18: dsetup32: Core components have been installed already, core installation is skipped. 11/16/09 13:32:18: dsetup32: IsIA64(): Windows 2000 or Windows 9x ... ( *abridged* ) 11/16/09 13:33:13: dsetup32: SetupForDirectX: InstallPlugIn() Succeeded. 11/16/09 13:33:13: dsetup32: start finalizing: phase: 62 - 62, total: 0 - 62 11/16/09 13:33:13: DXSetup: DSetupCallback(): Phase = 3, Steps = 0 11/16/09 13:33:14: dsetup32: Installation ended with value 0 = Installation succeeded 11/16/09 13:33:14: DXSetup: WM_APP_ENDINSTALL 11/16/09 13:33:14: DXSetup: ~CDXWSetup() my system: win98SE with 98SE2ME (Option 2) unofficial MSVC redist MS .Net2 Previous DX-9 redist that installable on win9x RP9 KernelEx Final-2 MD IE 6sp1 Component Update (2.9) M()zart' userenv.dll i found it weird, that it doesn't end up like those unsupported dx redist before.

thanks for your information, i made registry changes that finaly works, however after one tries, it wont working anymore. i suspected something probably wrong with the irc client itself. the suspicion was finaly confirmed with this change-log statement: yup, the irc client deletes the irc sub-key in HKLM and creates the new one on HKCU.for some reason which i don't know, IE / win98SE explorer shell, won't process the irc protocol properly, if it wasn't existed in HKLM. current workaround: downgrade the irc client to where that change hasn't been done.

how exactly registry need to be edited, so when i simply click url like this: (or typing such url in address bar) irc://irc.irchighway.net/certainchannel IE6 / windows explorer would launch irc program (ie: mIRC) accordingly ?

i'm also prefer NetBeui than "NetBios over TCP/IP". i got that knowledge from http://www.grc.com/su-rebinding9x.htm as Steve Gibson said, now i refuse to bind TCP/IP with any M$ services. (unfortunately, this can't be fully done in XP) even on my all winXP box, i also install the (unsuported) NetBeui, and do checkings to ensure that any TCP/IP transport would have "NetBios over TCP/IP" disabled.

win9x keep list of "installed" font in HKLM\Software\Microsoft\Windows\CurrentVersion\Fonts each of normal, bold, italic, bold+italic variety will takes up an entry. in normal case, entry on that registry will match existing font files in font folder. (if the font folder works properly use command prompt to see exacty what files on it). if the font folder doesn't work as it should ( no 'Install new fonts..' ), editing that registry will affect what font win9x will see.

awesome, another kex release (Final2), i'm gonna download it from sourceforge & install it right away. thanks Xeno86

all these floppy formating talk reminds me of the old days (pre win9x) when i still using: 2M utility i do rember formating diskette that normal dos' format.exe can't format (track 0 unusable stuff) into 2M-format, sometime if it works, it would reformatable again to standard dos format. i was curios

i have this experience: i plug another hardisk (its FAT32) that contain lots textfiles on it to a winxp system, i tried to find files that contain certain string. if the string contain spaces on it, winxp complain that i should enable indexing services on it. however if i plug that hardisk on win9x system, i can simply find such files without having the OS complain about it.