deomsh

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 XMGR 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 Hdaicout.hda

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.

Dencorso: Office XP can convert XLSX-files! 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".

The earlier test I mentioned failed on DirectX 9.0c. So far as I can remember I had at that time following specs: Win98SE, SP2.03 (last dutch service pack), IO.SYS update/patch and NUSB 3.3. No IE6, no KernelEx. Plus NDIS2-driver of course. I have been googling a bit, in connection with DirectPlay-problems registering DPNET.DLL was "somewere" mentioned. I just tried in "Run" with "REGSVR32 C:\WINDOWS\SYSTEM\DPNET.DLL (without the "" !). There was the succes-message from DllRegisterServer.