deomsh

@bz07 In the past I used a P4M800 board, Asus P5vd2-nvm. To find drivers for Windows 9x was a big problem, but finally I succeeded with AC'97 driver (ver:A4.00) from Biostar 8267R: alc850_6240.exe Your VEN/DEV is inside the WDM-inf's as far as I can see in my driver archive (major version only, no SUBSYS/REVisions). It's still available for download (you have to search the link with Google...). You can try if you like BTW: better do not use the setup, but unpack the exe with 7-zip and point during Windows's driver install directly to the WDM folder .

Somehow I succeeded with roytam1's manifest as a text-file, renamed to GetVersion.exe.manifest My earlier reported Windows 10 (x86) gives now: gv=0x42EE000A gvex=A,0,42EE,2,,0,0,100,1,0 And Windows 8.1 (64 bit): gv=0x25800306 gvex=6,3,2580,2,,0,0,300,1,0

Windows 7 Ultimate (x86) gv=0x1DB10106 gvex=6,1,1DB1,2,Service Pack 1,1,0,100,1,1E So last character of gvex is different. Regarding testing Windows 8.1: I'd like to help, but my programming skills are rather low. Maybe you can update Getversion or give some instructions? I don't know what to do with information here: https://docs.microsoft.com/en-us/windows/desktop/sysinfo/targeting-your-application-at-windows-8-1

My Windows 10 Pro was a (free) upgrade to Windows 7 Ultimate, years ago. Thats all I know. Today I tested a computer with Microsoft Windows 8.1 Pro (64 bit, sorry no x86 available): gv=0x23F00206 gvex=6,2,23F0,2,,0,0,100,1,0 BTW: my XPSP3 (x86) gave exactly the same values as IntMD's According to this document the return values for Windows 10/8.1 can be (should be?) the same as 8.0's: https://docs.microsoft.com/en-us/windows/desktop/sysinfo/operating-system-version

Here the GetVersion results for Windows 10 Pro version 10.0.17143 Build 17143 (or: Version1803 OS build 171430.590). gv=0x23F00206 gvex=6,2,23F0,2,,0,0,100,1,0</tt>

There are no definitions being used in kexstubs.log, except one Shlwapi-forward I need on my (almost) vanilla Win98SE installation: StrCmpLogicalW=>C:\Windows\Kernelex\W98\Shlwapi.IE6: ; MPC-HC 1.7.5 & MPC-BE 1.3.03; -> Shlwapi 6.0.2800.2006

Off Topic

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.