deomsh

Maybe here? https://web.archive.org/web/20170826223448/http://www.msfn.org/board/topic/175486-wpa2-for-windows-9x/

MPC-HC 1.7.5 is running with Kernelex 4.5.2016.18 and following stub: [User32.dll] KillSystemTimer= SetSystemTimer= UnregisterUserApiHook=

Last version of FFDShow (v1.3.4533.0 / ffdshow_rev4533_20140929_clsid.exe, ) is working fine, I am using Kernelex 4.5.2016.18 (Kernelex.dll v17; without Kstubs). Installer needs a NT compatibility mode, I used XPSP2. All four (!) configure-shortcuts are not working. By trial and error I found following workaround by editing "Target" in the shortcuts. Later I found that this workaround was reported already in June 2006 on MSFN, so the problem is much older than KernelEx. See also Drugwash (2013) and Loblo (2011). Schwups (2013) tried updating Rundll32.exe. C:\WINDOWS\RUNDLL32.EXE ffdshow.ax,configureAudio C:\WINDOWS\RUNDLL32.EXE ffdshow.ax,configure C:\WINDOWS\RUNDLL32.EXE C:\WINDOWS\SYSTEM\ff_vfw.dll,configureVFW C:\WINDOWS\RUNDLL32.EXE ffdshow.ax,configureDXVA All configure panels seems to be fine, but I didn't test VFW and DXVA. About Rundll32.exe: I used the original 4.10.1998 version.

@Goodmaneuver: I ment Jumpers KEX versions, 4.5.2015.3 and 6. I took a closer look at my LFN and it appears that the culprit was the use of the character " ï " (in Dutch normal). After changing to " i ", installation of LAV Filters 0.70.2 started as usual (but NOT in XP2 mode, only Windows 2003 SP1 or higher on my system). So the problem is different. Maybe we should discuss your problems with LAV Filters elsewhere.

@Goodmaneuver: About LAV Filters 0.70.2 there are two path-related problems. I hope this is still on-topic. First is that the installer (compat. mode minimum Windows 2003 SP1!) seems to work only from a folder without certain characters. Second: configuring LAV Filters without running a media file is possible after rewriting the shortcuts. Strip the path to the wanted LAV Filter in "Target". The full path is already in "Start in", In case of "LAV Audio Configuration" "Target" must become "C:\WINDOWS\rundll32.exe LAVAudio.ax,OpenConfiguration" and so on for the others (without qoutes!). This trick works for (latest) FFDShow configuration shortcuts too. On my system changes are correctly stored in the registry, no problems at all. "Enable system tray icon" is not working. I tried all KEX-versions i have, only 03 and 06 are missing - am not sure if they were ever published. All my versions are working on my new Almost-Vanilla installation, except 11 and 11a. Without KStubs LAV Filters are supported in 4.5.2016 and higher.

@jumper: about REGSVR32.EXE, I am not sure if relevant anymore, but here some details. Registering LAV Filters 0.70.2 (last XP version) with MSVCRT=MSVCR70.DLL in KnownDlls (linking three needed API's with Kstubs822 is not working: "_aligned_free", "_aligned_alloc" and "_aligned_malloc"). Other compatibility mode on REGSVR32 was only needed in case of using Total Commander's command-line. With "Run" or in Dosbox "Default" was good enough, I found out later. A bit strange was that "BASE" did the trick already in case of Total Commander's command-line (didn't try earlier). Is there a difference in KernelEx 4.5.2018 between "Use default compatibility options (KernelEx is enabled)" and "Use specific compatibility mode: Base enhancements (Api fixes + extentsions)", other than enabling "Advanced options" choices? After a full Windows 98SE reinstall, as Vanilla as possible (some DLL's only updated by DirectX9.0c, NUSB3.3, and Windows Installer 2.0 - NO Unofficial Servicepacks, NO new IE-version), "Default Compatibility Mode" was ALWAYS enough. Using the official LAV Filters 0.70.2 Installer ("Windows 2003 SP1 Compatibility Mode" minimum needed!) registering during installation already succeeded. Only remaining "thing" is that registering LAV Filters AX-files was NEVER possible with KernelEx "Disabled" for REGSVR32 (GetLastError 0x0000001F), different from all other media-files I tried.

I meant reinstalling the driver(s).

No. Files are not moved from Windows to System, as far as I know. Better try to reinstall again and again. Check your installation first with Run > SFC.

I use Ndis2-driver almost two years on my MB. No complaints, other than returning from 'Exit to MS-DOS' is not possible anymore because of some buffers flushing.

@Ruthan, Did you try ndis2-driver? Your MB seemed tot have a Realtek LAN. Inside following tread there is an Inf-file. If needed you can change to your PCI -VEN/DEV. There are a few other Realtek MS-DOS drivers too.

KernelEx 4.5.2018: Regsvr32.EXE has sometimes problems registering non-standard Win9x files. I had to set Compatibility mode "Windows 95" or even "Windows Millennium" for Regsvr32.EXE, even if the file that had to be registered was already set to needed (NT version) Compatibility mode.

At last I found time to test SATA in AHCI-mode. I did only about hundred tests, but there are already some result to report. 1) XHDD didn't cache the drives, as was to be expected from the readme. 2) In pure MS-DOS or Windows 98SE I had no stability problems as long as DBLBUFF.SYS was loaded. Once I tried without DBLBUFF.SYS, the Master Boot Record of one of my SSd's was damaged, I had to repartition the drive! 3) In MS-DOS I found the surprising result that use of secondary buffers (without smartdrive!) actually speeded up copying. 4) In Windows Buffers are doing not much in compatibility mode, but Smartdrive does. Although it makes coping in MS-DOS much slower, Windows gained speed. Even a little bit faster than in MS-DOS. 5) Maximum copy-speed of 500MB between SSD's (Vcache=131072, static): MS-DOS; BUFFERS=40,8: 38 MB/sec. MS-DOS; BUFFERS=10,8; INSTALLHIGH=SMARTDRV 2048 /L /U /V /B:57344: 15 MB/sec. WINDOWS; BUFFERS=40,8: 1 MB/sec. WINDOWS; BUFFERS=10,8; INSTALLHIGH=SMARTDRV 2048 /L /U /V /B:57344: 16 MB/sec. 6) Regarding DBLBUFF.SYS: forced use was not needed for stability, and slowed things down. In MSDOS.SYS Doublebuffer=1 must be set to load DBLBUFF.SYS (Doublebuffer=2 was not needed). IO.SYS loads DBLBUFF.SYS in case of DOS=AUTO (or omitted). In case of DOS=NOAUTO in CONFIG.SYS, DEVICE=DBLBUFF.SYS /D is equivalent. Or: DEVICE=SMARTDRV.EXE /Double_Buffer (loads DBLBUFF.SYS too, '.EXE' is needed in Device-statements). 'Forced' double buffering can be set with DEVICE=DBLBUFF.SYS /D+ ; or: DEVICE=SMARTDRV.EXE /Double_Buffer+.

Please be more specific. Using SYS C: must give a message like "System transferred". If your bootdisk is a floppy disk, or an usb-stick of the floppy-type, the command-line will show an "A" in case of booting from the bootdisk. If you used an usb-stick of the hdd-type, your command-line will show "C". Say Windows resides on the D-drive seen from the bootdisk, then SYS-command must be SYS D:

If you have a valid bootdisk SYS C: is worth a try.

In my Post of Oktober 6, 2018 I stated: 'Highest copy-speeds in WINDOWS (with static 128 MB VCACHE and NO MaxPhysPage!) were: - 4 MB/sec. with BUFFERS=20 - 17 MB/sec. with SMARTDRV 4096 /B:57344 and BUFFERS=4,0 - 5 MB/sec. with XHDD.SYS /R25 /S50 /H /O /P and BUFFERS=4,0 - 22 MB/sec. with XHDD in combination with Smartdrive (4 Buffers) In Windows Buffers and XHDD were really slow, Smartdrive performed the same as in MS-DOS.' In my latest experiments I met following problem: I cannot reproce anymore the slow speeds of BUFFERS only and standalone XHDD inside WINDOWS. I did many new tests, with following results. Highest copy-speeds in WINDOWS (with static 128 MB VCACHE and no MaxPhysPage): - 6 MB/sec. with BUFFERS=20 (DOS=UMB,HIGH,NOAUTO in CONFIG.SYS) - 2 MB/sec. with BUFFERSHIGH=20 - 14 MB/sec. with standalone XHDD.SYS /R25 /S50 /H /O /P and BUFFERS=4,0 I am using UMBPCI, so shadow-ram on my chipset seems to be slow (BUFFERSHIGH). The good news I found: copy-speeds with standalone XHDD are ALWAYS 14 MB/sec. (±10%) between ssd's, and 9 MB/sec. with standalone XHDD.SYS /B. Still slower than standalone Smartdrive, but not so bad. Maybe worth a try on your 2TB FAT32 SATA-partitions. I explored in depth the possibilities of XHHD with XMGR in WINDOWS, first without the use of Smartdrive. I concentrated on stability regarding the size of the XHDD-cache in combination with Vcache. Relevant setup Asrock 960GM-GS3 AMD FX-6300 4GB DDR3-1600 Geforce 6700XL 128MB PCIe Windows 98SE with basic updates (SP203dut, USBSP3.5 and NV82.69, DirectX 9.0c and a 16-bits NDIS2-driver (onboard ethernet). CONFIG.SYS DOS=HIGH,UMB,NOAUTO DEVICE=UMBPCI /I=CF00-CFFF /I=D000-DFFF (chipset specific!) DEVICE=XMGR /W DEVICE=LOWDMA.SYS DEVICE=XHDD /R1024 /Sxxx /H /O /P /G BUFFERS=4,0 ..... AUTOEXEC.BAT ..... UMBFILL SYSTEM.INI [386ENH] ;;MAXPhysPage=40000 IOS.INI ..... xhdd.sys ; uhdd.sys ; xmgr.sys ; rdisk.com ; lowdma.sys ; ..... WINDOWS hsflop.pdr disabled. DOS-Boxes must be (partly) working or Windows can't 'readout' the ssd's! Tests Opening 12 DOS-BOXES, playing MP4 with GOM player, DxDiag, multitasking during copying 500 MB between ssd´s, using all physical memory with Opera TAB's and opening 12 DOS-BOXES afterwards. Lowest value of MaxFileCache is based on R. Loew's formula: ´1/24 of Windows-RAM at minimum´ Results standalone XHDD Maximum stable combinations with Static Vcache: /S469 and MinFileCache=MaxFileCache=43692 /S256 and MinFileCache=MaxFileCache=196608 Maximum stable combinations with Dynamic Vcache: /S469, MaxFileCache=43692 without MinFileCache entry /S256, MaxFileCache=196608 without MinFileCache entry My experiments are suggesting that XHDD´s cache is counting too. There is some sort of trade-off, but non-lineair. Vcache It turned out to be possible to set MaxFileCache=43072 as absolute minimum, without a MinFileCache entry. At this value Vcache is static. The MinFileCache value set by Windows seems to depend MAINLY on RAM, only a few KB's vary with the value of MaxFileCache. I did a few quick tests: lowering RAM with the XHDD R-switch. If Windows ´sees´ 510,0 MB RAM MinFileCache is set to 21192 (21700608 Bytes). If Windows ´sees´ 255,0 MB RAM MinFileCache is set to 10348 (10596352 Bytes). With a MaxFileCache=41944 (1/25 of RAM) or lower and no MinFileCache, System Monitor shows a MaxFileCache of 800MB (838860800 byte = 819200KB) and MinFileCache of 42MB (44105728 byte = 43072KB). This is a corroboration of R. Loews formula: no MinFileCache is set (see picture below). As soon I set MinFileCache=256, shown MaxFileCache is the same value as in set in [vcache]. Holds for other values too. When there is a MinFileCache in SYSTEM.INI, the value ´set´ is shown by System Monitor.The lowest stable value I found is MinFileCache=256. Now MaxFileCache can be freely chosen, but must be equal or higher than the set MinFileCache value. Smartdrive Revisited AT THE CHOSEN VALUE OF RAM (1024MB), in combination with INSTALLHIGH=SMARTDRV 2048 /L /U /V /B:57344 (or LOADHIGH in AUTOEXEC.BAT) results with much more stability are possible, but the sum of XHDD´s cache and Vcache must not exceed 512MB. This time the trade-off seems lineair. See Q181862: prescribes lowest value of 512MB or 70% of RAM as maximum Vcache. The text of Q181862 I found in this link: https://www.computerforum.com/threads/autoexec-bat-files.50624/ Maximum stable combinations with Static Vcache: /S469 and MinFileCache=MaxFileCache=43692 /S50 and MinFileCache=MaxFileCache=473088 Maximum stable combinations with Dynamic Vcache: /S469, MaxFileCache=43692 without MinFileCache entry /S256, MaxFileCache=262144 without MinFileCache entry Lowest value of MaxFileCache can actually set to 43072 (System Monitor's MinFileCache readout). Copy-speed is highest with /S50 and MinFileCache=MaxFileCache=473088, 26MB/sec. Ultimate stability As my system depends heavily on 16-bit drivers, stability is an issue. Especially the 16-bits HDA-driver I am using, can induce lots of instability. With my most stable configuration I can listen to music during copying a 500MB file, almost without any disturbances - just like with the Windows protected mode driver (only as long as DOS-Boxes are unused - but depends on video-card). For 'ultimate stability' Vcache must be set static and really low, MinFileCache=MaxFileCache=1024, and XHDD's cache as high as possible (/S511). Smartdrive cache between 2048 - 4096, a cache of 1024 gives unstable results. BTW: lowest value of XHDD-cache I have used is 50MB, minimum is lower, but my version of XHDD Read-Ahead Buffer starts at 50MB - counts in speed! Newer versions should start at 20 MB. Not tested yet. Although a much bigger Read-Ahead Buffer would be nice, preferable with variable Buffersize.

Problem is that Widgets in the codec have default values. HDA2.DLL does not change these values (except a few). That can be done with the textfile HDAICOUT.HDA. If this file exists HDA2.DLL sent the Verbs in the file to the addressed Widgets and change values at start-up. Try this one. Worked for me in case of three different codecs (digital playback only). Copy the file to your Windows-directory and reboot. BTW in case of stability problems set MinFileCache=8192 & MaxFileCache=8192 BTW: see for latest version of HDAICOUT.HDA see: https://msfn.org/board/topic/178295-audio-driver-for-realtek-hd-audio-hardware/?page=10&tab=comments#comment-1163305

You're right about the /machine:at key. Speed of Himem is now the same as HimemX on my machine. Thanks a lot. I tried XMGR again. If loaded after Umbpci and with the /W-switch, speed is the same as the to others. I will explore further.

Lately I tested two identical 32GB SATA-II SSD's in MS-DOS compatibility mode. The results were a bit disappointing, but interesting. For the sake of comparison I partitioned the ssd's with 32k clustersize. The ssd's were optimized for speed (partitions starting at 1 MB). Benchmark: - In Windows 10 copy-speed with my 500MB testfile was 60MB/sec, between ssd's. Highest copy-speeds in MS-DOS were: - 37 MB/sec. with BUFFERS=20 - 17 MB/sec. with SMARTDRV 4096 /B:57344 and BUFFERS=4,0 - 56 MB/sec. with XHDD.SYS /S50 /H /O /P and BUFFERS=4,0 - 28 MB/sec. with XHDD in combination with Smartdrive and 4 Buffers So, in MS-DOS Smartdrive is outperformed by Buffers only! Apparently Smartdrives read-ahead buffer has little use in case of flash memory. XHDD did a magnificient job. Thank you Jack Ellis. Highest copy-speeds in WINDOWS (with static 128 MB VCACHE and NO MaxPhysPage!) were: - 4 MB/sec. with BUFFERS=20 - 17 MB/sec. with SMARTDRV 4096 /B:57344 and BUFFERS=4,0 - 5 MB/sec. with XHDD.SYS /R25 /S50 /H /O /P and BUFFERS=4,0 - 22 MB/sec. with XHDD in combination with Smartdrive (4 Buffers) In Windows Buffers and XHDD were really slow, Smartdrive performed the same as in MS-DOS. The combination of XHDD and Smartdrive had a better performance, but still less than copy-speeds on SATA-II Hard Drives I reported earlier. Copying from a ssd to a 128G(i)B partition on my 'new' 500GB Hard drive gave 31 MB/sec! Using XMGR.SYS with XHDD.SYS /R1024 /H /O /P /G to limit memory to 1GB, instead of HimemX (with /MAX=1048576), was about 5% slower. With HIMEM.SYS instead of XMGR: 9% slower than HIMEMX. BTW: with the XHDD /G-switch to limit memory, the maximum Smartdrive cache is about 4096KB. Although XHDD's cache is loaded above the value of the /R-switch, Smartdrive's cache is loaded below the /R-switch - inside the memory available to Windows. Posted with Opera 12.02

Same in my case. With the earlier Kernelex.dll Verify.exe is satisfied with the installation. I can see the new compatibility modes in the property sheet and there is a third choice (have'nt tested yet). No problems with Opera 12.02 or Firefox 3.28. Earlier problems I reported with MS Office Compatibility Pack & Kex17 with MS Office 2007 Word files seems tot be solved. Thanks a lot.

Some updates FYI, regarding: SMARTDRIVE 137GB barrier: Actually 137GB is 128GiB. Many programs give the GiB-size as GB, including Explorer and many Partition programs. SMARTDRIVE Maximum Cache Size: I found some "new" old information on Github. Thank you Jeff Parsons! Formula for Maximum Cache Size gives 36522 (KB) with ElementSize 8192 (Byte). Tested, in Windows only possible in combination with RDISK.COM or XHDD.SYS /R-switch (as mentioned earlier in this thread). http://jeffpar.github.io/kbarchive/kb/095/Q95531/ Note that SMARTDRIVE takes 64 KB with Maximum Cache Size, so Read Ahead Buffer MUST be loaded low with SMARTDRV /L SMARTDRIVE Maximum BufferSize: With (maximum!!) ElementSize 8192 the maximum BufferSize is 57344 (Byte). Tested: relation between Read-Ahead buffer size and copy speed still holds, the higher the better. http://jeffpar.github.io/kbarchive/kb/094/Q94604/ XHDD.SYS: There are many new versions (last update today - I will test soon), direct download from http://optimizr.dyndns.org/dos/drivers.html By accident I found that XHDD.SYS is not compatible with Windows protected mode floppy-driver HSFLOP.PDR (all two versions I know). Solution: disable Floppy-controller in Device Manager. Small price: Diskcopy is not possible with floppy station in MS-DOS compatibility mode. BTW: I have no other motherboard to test, so this holds at least for Asrock 960GM-GS3.

Lately I tested MSFN again with Opera 12.02. No problems anymore, I can sign in etcetera in normal Author mode. Only limitation I have is that the link to www.msfn.org/board is not visible, but can be reached by clicking in the upper left of a post (apart from some empty symbols). Thanks to the MSFN staff if they made this possible Posted with Opera 12.02 & Windows 98SE with original KernelEx

In fact, FileFormatConverters consists of three programs (wordconv.exe, excelcnv.exe and ppcnvcom.exe) with their own dll's and five common ones. Those three programs can be used one-way standalone (commandline) and do only conversions from the old to the new format. Another program, Moc.exe, can do conversions in both directions by giving the appropriate program the right "instructions". Moc.exe also has a function in saving the resulting file. Their interprocess "communication" is with help of a proxy. For wordconc.exe the proxy wordcnvpxy.cnv is used, for excelcnv.exe the proxy excelcnvpxy.dll and for ppcnvcom.exe the proxy ppcnvpxy.dll. If one of the Office programs opens or save a file DIRECTLY in the new file format, Office "communicates" by means of one of the proxy dll's. In case of the new Powerpoint file format, KernelEx SOMEHOW fails in the necessary interprocess "communication". Since 2014 I tried to find out what the culprit is, but my only succes was to establish commandline-conversion with ppcnvcom (ppt2pptx only, this is by design!). I hope one day the further development of KernelEx will help. Since I am not a programmer I can't do anything in that direction.

Set KernelEx 4.5.2 compatibility mode for excelcnv.exe to "Windows NT 4.0 sp6". If that doesn't work, for msxml5.dll too.

About Win3x: its also possible to "translate" HTTPS to HTTP with help of a web-proxy. Two problems: to find one that works and than to find one with reasonable speed. Lately I had a Win 3.1 internet project on Conforums. Sadly Conforums closed his doors, but if you are interested my last web-proxy test is still there: https://web.archive.org/web/20180413184337/http://win3x.conforums.com/index.cgi?board=net&num=1517876379&action=display&start=49 By the way: in my opinion Netscape Navigator 3.04 works "best".