deomsh

How is sound and stability (Explorer error you mentioned)?

According to HDACFG.INI your 'CODEC Index=$1', but this is the internal soft-modem.Can you switch it off? The HDA-codec is at 'CODEC Index=$0' according to HDAICOUT.TXT. This will be Realtek HDA-codec ALC883. During troubleshooting add following line in SYSTEM.INI to [386Enh] (.....) MinTimeSlice=80 Please report, and upload again if anything changes in HDACFG.INI

UPLOAD again: HDACFG.INI

Your AUTOEXEC.BAT and SYSTEM.INI looks good, although SMARTDRV /X is more safe. But HDACFG.INI is not populated, only Busmaster values. This file is written by HDA2.DLL, always in your Windows directory. Only HDA2.DLL is in the System directory! Please delete ALL instances of HDACFG.INI, reboot and upload this file again. Do NOT edit anything for now.

Please upload following files, so I can take a look: CONFIG.SYS AUTOEXEC.BAT SYSTEM.INI HDACFG.INI

Are you using Windows 98SE or Windows ME?

Lately I finished a second version of MKFATIMG.G4B, a Grub4dos script to make FAT-image files: https://github.com/deomsh/MKFATIMG.G4B This script descends from an earlier project in this thread: to write a FAT-volume on a ram-disk and map to hard-disk. See: https://msfn.org/board/topic/180597-exploring-setup-p-isdetectbus-and-grub4dos-8½-times-win98se-on-usb-drive/page/4/#findComment-1178197 However, the new script is more universal, only mapping is not a part of it anymore. But the chosen FAT-volume is still written (partly) to a ram-disk first, before dd-copied to file. File-creation uses Grubutil 'FAT'. In latest version 0.4 of MKFATIMG.G4B Loosely Linked Libraries mentioned in previous post can be applied to use Long File Names (FATLFN.LLL with dependency ATTRIBFT.LLL). If these libraries are not found, only Short File Names can (still) be used. The Small-help shows four modes of use: Instead of targeting an image-file, also writing a FAT-volume on a ram-disk '(rd)' is possible, only limited by available (high-)memory. But if an image-file is targeted, max 64MB is written to the ram-disk and later dd-copied to the start of the image-file. Because production of the image file with grubutil 'FAT' is only possible on a FAT-filesystem, maximum image-size is < 4G(i)B. If only 'size' and target are specified, there will be a disk-type and FAT-type produced depending on that size only, with no bootcode and no label, but with a valid MS-DOS uuid so each image is unique (unless some Swiss watchmaker is involved). Up to 4MB a floppy-image with FAT12, above up to 16MB a harddisk-image with FAT12, then a FAT16 harddisk-image up to 512 MB and above a FAT32 harddisk-image. Instead of 'size', also number of 'sectors' (512-byte only) can be specified, or even 'C/H/S'-values. With what I call 'Use 1', there are numerous switches to specify desired properties of disk and FAT-image. With 'Use 2' and 'Use 3' there is access to a set of predefined floppy-images or (old) AT/PS2 disk-types for harddisk-images. Still many switches available. Values used for predefined floppies are most of the time grabbed from 'Known_floppies2.xls' of Jaclaz: As an example a print-screen of the making of a 12240KB floppy-image while using Long File Names. According to my tests this is the biggest floppy that can be used with VMware: BTW if the switch '/BOOT' without ':OS' is used, the standard Win9x-bootcode will be written to the PBR, different for FAT12/16 and FAT32 (and to the MBR too in case of a harddisk-image). Script MKFATIMG.G4B has numerous bootcodes in textual form 'on board'. From MS-DOS 3.3 upwards, Freedos, ReactOS and Grub (Grub-bootcode is written to the PBR only). More information is in the Help. As a specimen I produced two 12240KB floppy-images (one without bootcode). Also two 3840KB floppy-images (one with Grub-bootcode too, and one without bootcode), because this is the biggest floppy accepted by Virtual Box (only if used from the start, no so good if changed during a session!). Use of the attached images with Grub-bootcode is simple: copy 'grldr' (comes with Grub4dos) and some menu.lst and other desired files to the image, for use in a virtual machine. Use of the attached images without bootcode: load the image with System Files of choice and boot directly using grldr grub4dos (NOT possible on MS-DOS 6.22 and below), or transfer desired bootcode too with some program like SYS.COM. As last print-screens the making of an almost 2GB FAT16 harddisk-image (values are rounded down by the script, also always ONE empty cylinder is added) together with mapping, copying Windows 98 system files and booting: BTW 'Use 4' is not showed, is used to copy an image on a ram-disk afterwards to file. With these use some files can by copied to the ram-disk first, to pre-load the image. Flop_12240k_(255t,2h,48s)_BCGRUB.zip Flop_12240k_(255t,2h,48s)_NOBOOT.zip Flop_3840k_(80t,2h,48s)_BCGRUB.zip Flop_3840k_(80t,2h,48s)_NOBOOT.zip

One of the better 'assets' if using Grub4dos is Grubutil 'fat'. Many of my scripts use this program to do basic operations on FAT file-systems. However, grubutil 'fat' can write Short File Names only. Almost three years ago I finished my first version of Loosely Linked Library ATTRIBFT.LLL, one of my ideas was to use this library to write a grub4dos script with same command-line as grubutil 'fat', but fully compatible with Long File Names. So again a front-end. This script is finished: FATLFN.G4B, and available on Github: https://github.com/deomsh/FATLFN I added a few extra switches and functions. 1) Because grubutil 'fat' does not copy the original date and time (Modification Date & Time), I added this functionality; 2) Because grubutil 'fat' can not overwrite read-only files, I expanded switch '/o' to '/o[:r]', same for deleting files ('del') with extra switch '/r'; 3) I added switch '/a', used to copy all attributes too (FAT-source only - also available in FATCOPY.G4B); 4) Function 'dir' shows Long File Names (if available). Like grubutil 'fat' always the whole directory is parsed (filtering on specific file-names would break the compatibility I wanted to be established); 5) New function 'dirx' shows Short File Names, filesize and associated Long File Names (if any). This function is more like 'dirx' in Windows 10 cmd. Also simple filtering on specific file-names is possible (ls-style); 6) New function 'dira' shows Short File Names, Attributes, Date & Time, Creation Date & Time (WRI) and Last Access Date (ACC). Filesize is not showed, not enough space in textmode/ 640x480 graphicsmode. Also simple filtering on specific file-names is possible (ls-style); 7) New function 'dellfn' will delete Long File Name only (actually not dependent on the existence of an associated Short File Name, orphaned duplicates in the targeted directory will be deleted too). Functions 'ren' and 'copy' of grubutil 'fat' are enriched with possibilties to add or change Long File Names. For example change case of a Short File Name, which for instance is NOT possible in Windows 10 (on FAT file-systems). Microsoft advises to do a two-step rename: https://answers.microsoft.com/en-us/windows/forum/all/how-to-change-file-names-from-lower-case-to-upper/2305aad9-5743-4e95-83bd-64b191e312eb This time I used the NT-method to abbreviate Long File Names: first four identical (resulting) Short File Names ('seen' as full 8+3 SFN) in a directory are tilded '~1'-'~4' after the first six characters of the name-part of the Short File Name. If more Short File Names would be identical, they have same first TWO characters, followed by a hash of the Long File Name and tilded '~1' up to '~9'. FATLFN.G4B is using following functions of ATTRIBFT.LLL: getsfnpath, getsfn, getlfn, makelfn, dellfn, isreadonly, getattrib, setattrib, getntcasebyte, setntcasebyte, getdate, setdate, gettime, settime, getdatetimeattriball and calclfnhash. I also made a Loosely Linked Library version: FATLFN.LLL (not used yet). This gives a library with a dependency to another library, because ATTRIBFT.LLL is still used. I hope I am not creating my own lll-hell . One print-screen with new functions 'dirx' and 'dira' (more on Github): BTW: it is funny the 8+3 'LOWCASEx' Short File Names have no associated Long File Name. This is because made on a NT-file-system, only - what I call - the NT-casebyte is set in the Directory-entry. No Long File Name is written if name-part, extension or both are FULLY lowcase (if only one is lowcase, the other must be HIGHCASE, otherwise a Long file Name will be written). But with grub4dos' internal function 'ls' this byte is read-out and corresponding case is showed.

A long time ago already I announced an outline of front-ends for grubutil 'fat' (and two for internal grub4dos function 'ls' too). I fully forgot my announcement, although I use all these scripts for years. Lately I finished them all and published them on my Github page. In the first version(s), all scripts could handle Short File Names only (except for ls-directory parsing in FATLSDIR.G4B). Now the other three scripts can handle Long File Names too, if the Loosely Linked Library ATTRIBFT.LLL is present. The concept of Loosely Linked Library is an idea of Wonko the Sane (Jaclaz) and discussed on reboot.pro (sadly still 'down', maybe forever?). Script FATCOPY.G4B, front-end for grubutil 'fat' function 'copy', was published earlier in this thread, latest version 0.3: Version 0.4 has following changes: Version 0.4 NEW: switch /lfn[:]@ to add Long Files Names from previously saved to XXXXXX#n/@n[.EXT]-files to 'tilded (XXXXXX~n[.EXT])' Short File Names (needed: Loosely Linked Library ATTRIBFT.LLL) NEW: switch /lfn[:case] to copy Long File Names (needed: Loosely Linked Library ATTRIBFT.LLL) NEW: switch /z to copy zerobyte-files (NOT possible if source is NTFS) NEW: switch /a to copy all atrributes on source files to target files NEW: switch /maxfiles:n to limit maximum of copied bytes NEW: switch /maxfiles:N to limit maximum of copied files NEW: dialog to overwrite read-only files, do in advance with switch /r IMPROVED: switch /sfn:@ has auto-set tilded file number by read-out of already saved Long File Names IMPROVED: protection against errors on command-line Changes to switch in use to change MDBASE Various bugfixes Script FATLSDIR.G4B, front-end for grubutil 'fat' function 'dir' or for internal grub4dos function 'ls', was discussed earlier in this thread. Version 0.1 is ready, with more than twenty switches, including basic one's like '/b', '/s', '/w' and '/p'. Like 'DIR' wildcards are supported, but only simple asterisk-wildcards (even ONE '*' at the end of last directory in PATH), switches like '/[-]x:~' and '/[-]y:DIR' can be used to filter on chars in file/ folder names. Also the special switches '/size:n' is worth mentioning, to filter on filesize. On next print-screen the use of this switch to find all zero-byte files in a directory, and in all it's sub-directories. Watch the difference between output of FAT-directory parsing and ls-directory parsing: Script FATMKDIR.G4B, front-end for grubutil 'fat' function 'mkdir', is small, compared to the other three. Purpose is to make full path, convert Long File Names to Short File Names, or write the LFN's as external attribute to file, or to make Long File Names using ATTRIBFT.LLL. Script FATLDEL.G4B, front-end for grubutil 'fat' function 'del', to to delete files and folders, or whole sub-directories, Deleting Long File Names is possible if using ATTRIBFT.LLL. As an illustration a print-screen, also with use of switch '/t', for ' trial' (Also present in FATCOPY.G4B and FATMKDIR.G4B).: All scripts, with more information an many print-screens, can be found on : https://github.com/deomsh

I found this, maybe helpfull? ; Filename: ssigd.inf [...] [......] [Manufacturer] %Intel%=Intel.Mfg ;=============================================================================== [Intel.Mfg] %Intel% %i810% = ssigd_wht, PCI\VEN_8086&DEV_7121 %Intel% %i810DC% = ssigd_wht, PCI\VEN_8086&DEV_7123 %Intel% %i810E% = ssigd_wht, PCI\VEN_8086&DEV_7125 %Intel% %i815% = ssigd_wht, PCI\VEN_8086&DEV_1132 %Intel% %i830m% = ssigd_alm, PCI\VEN_8086&DEV_3577 %Intel% %i835% = ssigd_alm, PCI\VEN_8086&DEV_357B %Intel% %i845% = ssigd_alm, PCI\VEN_8086&DEV_2562 %Intel% %i855% = ssigd_alm, PCI\VEN_8086&DEV_3582 %Intel% %i865% = ssigd_alm, PCI\VEN_8086&DEV_2572 %Intel% %i915GD0% = ssigd_nap, PCI\VEN_8086&DEV_2582 %Intel% %i915GD1% = ssigd_nap, PCI\VEN_8086&DEV_2782 %Intel% %i915AL0% = ssigd_nap, PCI\VEN_8086&DEV_2592 %Intel% %i915AL1% = ssigd_nap, PCI\VEN_8086&DEV_2792 %Intel% %i945LP0% = ssigd_nap, PCI\VEN_8086&DEV_2772 %Intel% %i945LP1% = ssigd_nap, PCI\VEN_8086&DEV_2776 %Intel% %i945CT0% = ssigd_nap, PCI\VEN_8086&DEV_27A2 %Intel% %i945CT1% = ssigd_nap, PCI\VEN_8086&DEV_27A6 [....] [Strings] ;---------------------------------------------------------------------- ; Localizable Strings ;---------------------------------------------------------------------- Intel="Intel Corporation" DiskDesc="Embedded Installation" i810="810 Embedded Graphics Controller" i810DC="810DC Embedded Graphics Controller" i810E="810E Embedded Graphics Controller" i815="815 Embedded Graphics Controller" i830m="830M Embedded Graphics Controller" i835="835 Embedded Graphics Controller" i845="845 Embedded Graphics Controller" i855="855 Embedded Graphics Controller" i865="865 Embedded Graphics Controller" i915GD0="915G/915GV/910GL Embedded Graphics Controller Function 0" i915GD1="915G/915GV/910GL Embedded Graphics Controller Function 1" i915AL0="915GM/915GMS/910GML Embedded Graphics Controller Function 0" i915AL1="915GM/915GMS/910GML Embedded Graphics Controller Function 1" i945LP0="945G Embedded Graphics Controller Function 0" i945LP1="945G Embedded Graphics Controller Function 1" i945CT0="945GM Embedded Graphics Controller Function 0" i945CT1="945GM Embedded Graphics Controller Function 1" [....]

Do you mean this driver? https://vintage2000.org/windows/windows_98#intel_945gm_display_driver_for_windows_98

If you mean a Window's DOS box: try "DIR /S" after changing to your USB-drive letter (without quotes). Total used and free space will be shown. BTW can take a LONG time in your case... Screenshot shows my 16MB (virtual) drive (some space is used by directory clusters, not counted):

Inserting earlier part In the patent text of 'Common name space for long and short filenames' is stated something like that (but not if a short filename API is used). Somewhere in the patent text is a forbidden part, so use google (see steps 82, 84, 86 in patent US5579517) Workaround with picture:

Also Save As 8.3 filename in Windows 98SE with Notepad with different case, gave results as found earlier (except if all characters are uppercase of course). My conclusion is that in the FAT32 spec a conflict between different files/ directories with same Long and Short File Name is described, if the names are different in case only. Which makes sense on a case-insensitive file system (but case-rententive, see https://jpsoft.com/help/filenames.htm).

Also Save As 8.3 filename in Windows 98SE with Notepad with different case, gave results as found earlier (except if all characters are uppercase of course). My conclusion is that in the FAT32 spec a conflict between different files/ directories with same Long and Short File Name is described, if the names are different in case only. Which makes sense on a case-insensitive file system (but case-rententive, see https://jpsoft.com/help/filenames.htm).

Tried on Android/ Firefox (desktop site) @jumper Thanks a lot. Scandisk never complained (only if I made a mistake during the develoment of my LFN-driver ATTRIBFT.LLL). I did an extensive search. In the wikipaedia '8.3 filename' article is stated that a 8.3 mixed case file name is used as the Long File Name, the Short File Name is simply converted to uppercase. See https://en.wikipedia.org/wiki/8.3_filename

Tried with Android/ Firefox (mobile site and desktop site) Forbidden again

Tried with Android/ Chrome (desktopsite) Forbidden too

Problem responding: 'Forbidden You don't have permission to access this resource.'

I am working on a new version of FATCOPY.G4B. The most important new feature is copying Long File Names, which is not possible with grubutil FAT (the driver I use to make directories and copy files to a FAT-target). In case of Long File Names on the source, I use a Loosly Linked Library to create Long File Names on the FAT target. The concept of a 'LLL' is developed by Wonko the Sane (Jaclaz) and discussed on reboot.pro (reboot.pro is currently down). Real Long File Names are not my problem, but I am not sure how to handle case with Short File Names (normal 8+3 MS-DOS file names, but not all characters uppercase). So far I am simply making a Long File Name entry containing the 8+3 Short File Name with case (in Unicode). The original Short File Name entry is copied directly after the Long File Name entry, and the original Short File Name entry is 'deleted' by writing 0xE5 to first position. So far eveything went well. Lately I was reading the FAT32 specification again. There was stated identical Long and Short File Names, only differing in case are not allowed. Section 7.4: 'Any name within a specific directory, whether it is a short name or a long name, can occur only once (difference in case is ignored and such names must be considered as conflicting' https://academy.cba.mit.edu/classes/networking_communications/SD/FAT.pdf This will lead to the 'ugly' solution making tilded' Short File Names to just store the case information in the Long File Name entry. However I found out Windows does not obey this 'Microsoft Rule', as can be seen on print-screen below: On the second line can be seen that output of 'ls' is a Short File Name, but all lowercase. First *somehow* I expected the NT-casebyte on offset 12 in the 8+3 entry. This was not the case however, offset 12 is zero, not 0x18 to 'show' name AND extension lowercase (see line 7 of 'DESKTOP INI' and the line of ' INDEX DAT'). As can be seen, the Long File Name entries differ in case only. BTW I just found out these files came from my latest Windows 98SE installation, so the NT-casebyte was not an option. So far my script FATCOPY.G4B, with help of my Loosly Linked Library, gives exactly same results if the corresponding command-line switch is set (but of course without the copy/ delete part of the Short File Name copied by grubutil FAT). See next print-screen: Another new switch, '/a', copies ALL file attributes given in the Short File Name entry (except Creation Date and Time). BTW grub4dos script ATTRIBFT.G4B is a front-end for my Loosly Linked Library, for use on the command-line. My question is if it can be considered as safe to use identical Long and Short File Names, only differing in case. And why is Windows not following the specs? Or have I missed something?

Congratulations. But: according to step 6 of the manual you should have been in 'C:\WINDOWS\SYSTEM' already (or 'C:\%windir%\SYSTEM' in case of another WINDOWS-directory). So changing PATH shouldn't be needed.

I just tested the PATCHNVC.EXE on NVCORE.VXD renamed to NVCORE.BAK inside Virtual Box 7 in MS-DOS safe mode (no Windows installation). No errors. I found about 5 patched locations, seems to coincide with HEX-strings inside PATCHNVC.EXE. The last one for instance: If I repeat the proces with patched NVCORE.VXD renamed to NVCORE.BAK I get a message: I have no 512MB 7xxx NVIDIA card, so no testing possible FOR ME...

Check if 'bootGUI=1' in MSDOS.SYS (without qoutes)

My system is rather unstable with Watler's HDA2.DLL, really needs most stability measures mentioned in this thread. About SBEMUL/SBMIDI: as far as I know these need a WDM-driver, which HDA2.DLL is not. But VDMSound can be used, according to @sifonium even for midi with the Yamaha-driver. Jack-detection through software is not supported by HDA2.DLL, only if hardwired like on old-fashioned hifi.

FileFormatConverters.exe is version 12.0.6500.5000, the version number 12.0.6514.5001 is after installation. All names for the same, but compatibilitypacksp3-kb2526297-fullfile-en-us.exe is latest update. I can't remember if it can be used standalone. BTW you can open these packs with 7z if you want to see what's inside.