deomsh

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.

@Cixert I can not help you with your problem. I hope @actinium will respond, but 2019 is a long time ago. If you want to install the compatibilty pack, use fileformatconverters.exe first. Discontinued by Microsoft, but easy to find. For instance here: https://www.filehorse.com/download-office-compatibility-pack/ (latest version I am aware of is Office Compatibility Pack 12.0.6514.5001). Afterwards use compatibilitypacksp3-kb2526297-fullfile-en-us.exe, for instance from https://filehippo.com/download_microsoft-office-compatibility-pack/ There are a few minor updates too you can search for. BTW: as such Office Compatibility Pack is language-neutral, only install-language and some messages are localized. Yesterday I installed Office 2003 from the original CD-ROM on my new Windows 10 computer. It is a miracle the activation-servers are still working. Also Windows Update provides still updates! But NOT Office Compatibility Pack....

Difficult. Are ALL energy-saving measures switched off, both in your BIOS and in Windows? Also: NO screensaver! You can try adding following line to your AUTOEXEC.BAT, just before the HDATSR-line: SMARTDRV.EXE /X /L /V /B:57344 Speeds up file-reading operations too, to compensate for the ultra low vcache setting. Watch: by design SMARTDRV.EXE can only be used on partitions below 128 GB (about 127+ GiB) . Also, add to SYSTEM.INI section [386Enh] following entry: MaxPhysPage=20000 (if I am right 20000=512MB, 40000=1GB, 80000=2GB and C0000=3GB, you can always go up). From Device Manager: set Hard-Drive Read-Ahead to max (64KB), CD-settings all to max too and change Role of Computer: there are three choices, maybe Networkserver or something like that. Also try reducing Video Hardware Acceleration, step-by-step. Measures one-by-one and reboot in between.

Allright: 1) copy WAVEOUT.EXE to your Windows directory (from your HDADRV9.L); 2) open HDACFG.INI with Notepad. According to the ALC888 datasheet the volume widget is probably 0C So try VolumeWidget=$0C Watch: a zero, not O Save and reboot; 3) open WAVEOUT.EXE. If the main screen is empty click the big button at the upper left; 4) try adjusting volume with the two sliders: one for left channel, one for right.

The max value I have ever used is MinTimeSlice=120 In Device Manager there should be a High Definition Audio Controller now. Sound devices are found in "Sounds and Audio Devices" / "Multimedia" (as part of Control Panel). Apps/ games should work with HDA2.DLL if they use Wave Out/ Direct Sound, but NOT if WDM-drivers are needed.

Normally not, only (much) less cache, so reopening files will be slower, probably copying too. But one user had problems switching keyboard layouts. This user solved that problem by setting MaxFileCache=8096 8192 USB should give no (real) problems. You also can try with following stabilizing measure: 2) add to SYSTEM.INI [386Enh] following entry MinTimeSlice=80 And reboot. This will make your system less responsive, but much more stable. Try afterwards your USB CD-ROM.

HDATSR is installed, so max memory should not be a problem. Best take first stabilizing measure: 1) add to SYSTEM.INI [vcache] following entries MinFileCache=1024 MaxFileCache=1024 BTW the file SYSYEM.INI is in your Windows directory. Most comfortable is edit with: Windows key => Run => SYSEDIT and activate SYSTEM.INI. Than: reboot.

Posts crossed. Congratulations! We can try WAVEOUT.EXE. Please upload two files mentioned above first.

There are four possibilities: 1) your hear Windows startup sound. In that case only volume sliders of WAVEOUT.EXE have to be configured; 2) you hear some crackels, in that case we have to configure HDAICOUT.HDA; 3) you hear nothing, in that case we will have to look at your chipset registers; 4) crashing of Windows and/ or Error 202. In that case we have to take stabilizing measures first (not done by my current INF-file). In any case: please upload HDACFG.INI and HDALOG.TXT. They should be in your Windows directory.

I am working on a new version of my GENHDA16.INF. Be aware use of the Win3x HDA-driver on Win9x is experimental. There can be severe stability problems, I never advocated to use this driver! You can find latest version of HDADRV9 on: http://turkeys4me.byethost4.com/programs/index.htm but if you want to try version 9.K: be my guest. Instructions: 1) make a directory, say C:\HDAFILES (best short 8+3 file-name); 2) copy following files to that directory: HDA2.DLL, HDATSR.EXE, HDARUN.EXE (all found in HDADRV9) and also GENHDA16.INF ; 3) update driver of PCI-card with yellow exclamation mark from Device Manager, choose 'Ask disk' (or something like that), point to your HDA-files directory and proceed. You probably will be asked to reboot twice; 4) listen carefully with headphones if you hear anything after last reboot. BTW my INF-file will copy files and will make all necessary entries. Also you should afterwards be able to uninstall the driver from 'Software'.

Watlers HDA-driver is made for Windows 3x. It comes with an Win3x compatible INF-file. You can use this one with Wizard New Hardware (manually!), or you can use the Win9x compatible INF-file at start of the thread by copy/ paste in Notepad and rename to extension '.INF' If using Watler's INF-file you must check if HDA2.DLL is in '\WINDOWS\SYSTEM' (if '\WINDOWS' is your windows-directory. In '\WINDOWS' following files must be present: HDATSR.EXE, HDARUN.EXE and WAVEOUT.EXE (last file is not copied by my INF-file). In SYSTEM.INI section [drivers] there must be an entry 'wave=HDA2.DLL', or 'wave1=HDA2.DLL' (my INF-file uses 'wavehda=HDA2.DLL'. In AUTOEXEC.BAT line 'HDATSR' must be present. Watch: always without qoutes. HDAICOUT.HDA is only needed in special cases, so for now forget about it. Is everything clear to you? EDIT: current version is HDADRV9.L. Earlier version 9.J (version 9.K existed for a short time only on Watler's file-site. I have not used it regularly).

In that case I think were done. You tried 'pcipatchB=$7900' earlier. You know what to do if you want your headphones back.

I have done some reading in the ICH9 datasheet. It seems MSI is disabled by default. Maybe you are lucky if you enable MSI with 'pcipatchB=$6281' (if my reading/ hex-counting of Intel's io-controller-hub-9-datasheet, paragraph 18.1.27 is correct). As always: at your own risk (if any). Do not forget to study HDALOG.TXT too, if you want to try.

Sad. MSI is Message Signaled Interrupts (PCI-bus mechanism). Personally I do not understand them, but MSI was mentioned in a Linux source in relation to the High Definition Audio Controller. If you want to read more: https://wiki.osdev.org/PCI

Setup /p i is always good. On my 2011 (desktop) motherboard needed too. But I ment your laptop's BIOS setup. Are there any switches regarding energy savings or MSI?

Sorry to hear that. In my opinion on the side of Watler's HDA-driver nothing can be done further. But how about the Setup of your laptop? Are their for instance energy-savings which can be switched off? I found some manual of your laptop, but this was not clear for me.

Maybe I have been on the wrong track and is this function ment to set the PCI-device manually (so the HD-Audio Controller, who communicates with the codec). I did a wide internet-search on 8086:293E, always 00:1b.0 is mentioned, so same as your values. So best REMOVE lines in HDACFG.INI I suggested above. The fact that HDALOG.TXT first identifies the right codec on $0 and than switches to codec $2 can also mean a timing problem. Especially because Verbinterface=$1 didn't work on your system. Timings can be adjusted. I suggest to experiment with the wait-states in steps of 50 (msec), up to 1000 (1 second). Your current values in HDACFG.INI are: wait1=$100 wait2=$100 Best first go UP, so starting with $150 both. Check HDALOG.TXT after each reboot too.

And what happens if you delete these four lines and only add SEARCH=FALSE to [HDA_293E8086,3621103C] below the line PCI_FUNCTION=$0 ?

While reading some old posts I realized we didn't try new functionality of HDA2.DLL version 9.L to select 'Codec index'. If you like, you can add some lines to HDACFG.INI. New entry [HDA] should look like this: [HDA] TSR=TSR Found PCI_VID=$8086 PCI_DID=$293E PCI_BUS=$00 PCI_DEVICE=$1B PCI_FUNCTION=$0 SEARCH=FALSE BTW first three entries are present already, so you only have to add last FOUR lines. I interpret 'PCI_FUNCTION=$0' as general codec address, but so far I am not aware of any succesfull testing of this feature. If you want to try: check after reboot if 'Codec index' changes.