deomsh

I am using RTGND.DOS, with other NDIS2-drivers I believe only the file name has to be substituted everywhere (untested)! Relevant entries (directory as you like) -------------------------------------------------------------- CONFIG.SYS -------------------------------------------------------------- . . DEVICE=C:\DRIVERS\NDIS2PKT\PROTMAN.DOS /I:C:\DRIVERS\NDIS2PKT DEVICE=C:\DRIVERS\NDIS2PKT\RTGND.DOS DEVICE=C:\DRIVERS\NDIS2PKT\DIS_PKT.DOS . . . -------------------------------------------------------------- -------------------------------------------------------------- AUTOEXEC.BAT -------------------------------------------------------------- C:\DRIVERS\NDIS2PKT\NETBIND.COM . . REM AFTER YOUR PATH STATEMENT (PATH ...., or SET PATH=.... ) set Path=C:\DRIVERS\NDIS2PKT;%PATH% . . -------------------------------------------------------------- -------------------------------------------------------------- PROTOCOL.INI -------------------------------------------------------------- [protman$] DriverName=protman$ [RTL8168] DriverName=RTGND$ Medium=_auto Interrupt=11 IOBase=0xe800 [PKTDRV] DriverName=PKTDRV$ IntVec=0x60 ChainVec=0x65 BINDINGS=RTL8168 -------------------------------------------------------------- In PROTOCOL.INI instead of [RTL8168] AND BINDINGS=RTL8168 the right NIC-code should be used twice, but is not necessary in my opinion, as long they are identical. Needed is to substitute the name-part of the filename of the NDIS2 driver in DriverName=RTGND$ ($ at the end, no extension!). Do NOT change the [PKTDRV] entries. For other NDIS2 driver-specific entries needed in PROTOCOL.INI study the INF/INI/NIF-files coming with the NDIS2-driver, or take a look in %WINDIR%\PROTOCOL.INI if NDIS2-driver is installed in Windows 9x (for my NIC RTGND$ uses: Medium=_auto / Interrupt=11 / IOBase=0xe800). Shim in use is DIS_PKT.DOS 4733 Bytes 05/01/1998 The files PROTMAN.DOS and NETBIND.COM are part of MSClient. How to get them and the shim see: http://wiki.freedos.org/wiki/index.php/Networking_FreeDOS_-_NDIS_driver_installation Although the wiki states otherwise, the PROTMAN.DOS /I switch, pointing to the directory where all files reside, is needed - in my setup at least. BTW: don't install MSClient. Further: I am not sure if the path-entry is needed, my setup is already 2½ years old. Update: the PATH-entry isn't needed on my system!

Nice! Because my (BIOS Legacy USB1.1)USB flash drive was a bit slow, I tested running from a 420MB 502MB Grub4Dos Memdrive. With LINKS.BAT loadtime for duckduckgo homepage is only 2 seconds. Do you want me to add my RTL8168 NDIS2/shim setup in this thread?

@Wunderbar98 Thanks a lot, everything is working as expected. My only problem was the packet driver. My RTL8168 provides for a NDIS2-driver, but nowhere a packet driver around. Luckily I found an old Windows 3.1 project on my harddrive which uses a shim to connect to the NDIS2 driver. (-: Posted with Links-2.21

@sweaterfish Thanks for testing. Setting only VolumeWidget in HDACFG.INI to $04 should give WAVEOUT.EXE full control. So the default of 48kHz is NOT the best choice. All in all the standard Output verbs sent by HDA2.DLL are the best choice. In that case their is no reason to maintain the $004-verbs in HDAICOUT.HDA and the Widget lines in HDACFG.INI can set to their original $04-values. Not only sound quality matters, the $011707C0 verbs is ment to activate the headphone amplifier needed to drive a low-impedance device (see the AD1984 datasheet). I don't know if their are any risks involved without, but that's all yours. I am not liable for it, I even never advocated use of HDA2.DLL! On my ALC662 codec (Realtek) enabling the headphone amplifier introduces noise, so I use 70740 only. Good! In my drawing the verbs for Aux are included (CD/DVD - not standard on Thinkpad X61 I believe, but an extension for the slim Ultrabay). On my system analog CD/DVD-audio redirected through the codec sounds much better than digital CD/DVD-audio. No, HDA2.DLL is playback-only by design. Although ADC can be enabled on the codec level and will be sent to the Azalia Link, nothing else will happen. The Runtime error you mentioned is the main reason to be very careful using HDA2.DLL. It can have very bad consequences. After a soft/hard reset Windows sometimes will use auto-scandisk. ALWAYS let the program finish and watch carefully SCANDISK.LOG afterwards. In general I don't agree switching Autoscan off in MSDOS.SYS. Scandisk is your best friend, but like best friends his comings and goings are not always desirable. Stability issues are reported while copying files together with audio playback. Also during simultaneous downloading of files and running DOS-boxes (the Windows command-line CONAGENT.EXE is involved too). But these issues are also dependent in de video card used! Know stability measures are: setting SYSTEM.INI [vache] MaxFileCache=1024 AND MinFileCache=1024, set [386Enh] MinTimeSlice=100. Also using SMARTDRV.EXE /X /L /V /B:57344 can be helpful (and speeds up file reading operations to compensate for the ultra low vcache setting - by design SMARTDRV.EXE can only be used on partitions 128 G(i)B max). During software installations / big copy-operations I always switch HDA2.DLL off with a semicolon before the HDA2.DLL wave(hda)-entrance in SYSTEM.INI and reboot Windows.

@sweaterfish Thanks for your comments. I made a simple drawing of the Functional Block Diagram for AD1984. Left I added the basic HDAICOUT.HDA with some possible extensions. I'm not fully sure about the Input Mixer connections, I believe there is an error in the datasheet. The original scan was 6 MB, so 256KB will not give the same quality anymore. Would you do me the favor to test the basic part of HDAICOUT.HDA with all three widgets in HDACFG.INI set to $FF? I want to know if the verbs in HDAICOUT.HDA can control everything (already tested on my H61 board and in Virtual Box). If sound is okay, I also would like to know if WAVEOUT.EXE is working without the right VolumeWidget in HDACFG.INI.

Please

Yep, see Windows 98 Resource Kit "Appendix C Windows 98 INF Files" and "Appendix D Msbatch.inf Parameters for Setup Scripts". Files with an ini-structure are easy, CONFIG.SYS/AUTOEXEC.BAT are complicated.

@sweaterfish Congratulations, you deserve it! Just for the record: Was pushing the physical volume buttons needed? Was commenting out the 'Codec reset'-verbs REALLY needed? Are Headphones/Speaker both working, and is the speaker muted if you plugin headphones? Is it possible to change volume with WAVEOUT.EXE? Further: would you be so kind to upload HDALOG.TXT and HDAICIN.TXT, so I can see what's going on myself? Could be useful for future troubleshooting of other laptops (I don't have access to laptops with High Definition Audio codecs, although there are a few in my reach - I possess no admin rights whatever on these machines, can't even boot from USB ).

@sweaterfish Good testing, strange your HDACFG.INI is now populating in all modem variants. Please describe the crackles in detail: are there three during booting Windows, or when starting an audio file in a media player? Further: EAPD is a laptop ´thing´, but I searched for Thinkpad X61 only. Keep both possibilities in all your tests to be sure. I do not understand why Takashi Iwai wants to use DAC_1, but there is a sidenote (typo is made by him): "* FIXME: * For simplicity, we share the single DAC for both HP and line-outs * right now. The inidividual playbacks could be easily implemented, * but no build-up framework is given, so far." Be aware the default connection of Mixer 07 is to DAC-widget 03, Mixer 0A to DAC-widget 04. But there appears to be Selector widget 22 who can set Mixer 07 to DAC-widget 04. It's in the datasheet, but in this AlsaInfo.txt more in detail. You only have to 'read' the Codec information (compare with output of various buttons of INTELHDA.EXE's widget Tab): http://launchpadlibrarian.net/176533849/AlsaInfo.txt Yeah, last hexadecimal value (four bits) should be zero for power state D0 (fully on). That's our only concern here. The SET-verb can only set one of the power states, but the GET-verb can provide more states for 'software' (more details in Intel' High Definition Audio Specification page 151-159). I am not sure about the values of INTELHDA.EXE, a version of HDA2.DLL is part of this program. A few things for further I experiments for now: 1) Don't forget to test if pushing the physical volume buttons gives any difference. 2) First I'd like like to see HDAICIN.TXT after commenting out the first to verb-lines in the 'debug' version HDAICOUT.HDA I made you (commenting out with a semicolon). So without Codec Reset, but with a full new boot (first fully switching off the machine for a minute or two). 3) Change lines in HDAICOUT.HDA one by one, Reboot to MS-DOS/Exit to Windows in between is much faster, you won't lose your other codec-settings. If the GET-verbs give same output before, and after a SET-verb, that SET-verb is unnecessary. Comment those verbs out, they will not be shown up in HDAICIN.TXT anymore. Editing using 'Run' is fastest in my opinion (Ctrl+Esc => Run => C:\Windows\Notepad HDAICOUT.HDA and same procedure for HDACFG.INI).

@sweaterfish I made a first draft of a Thinkpad X61 specific version of HDAICOUT.HDA so just rename and put in your Windows folder. It's partly based on a Linux plugin for your codec brand. https://review.clip-os.org/plugins/gitiles/clipos/src_external_linux/+/21949f00a022e090a7e8bc9a01dfca88273c6146/sound/pci/hda/patch_analog.c In this document I found also: /* Lenovo Thinkpad T61/X61 */ SND_PCI_QUIRK_VENDOR(0x17aa, "Lenovo Thinkpad", AD1984_THINKPAD), I can't find the exact correspondence with the HDA controller registers, but pcipatchB=$17AA is worth a try, of course first without HDAICOUT.HDA. 0x17aa seemed to be subsystem vendor id. It's in your picture of the HDA controller registers too (W16). Now you have three two pcipatchB testing possibilities together with HDAICOUT.HDA: $0000, $7900 and $17AA. Combined with three different modems settings gives nine six. Best start with your latest discovery (physical modem removed, but switched on in BIOS). Please upload afterwards HDACFG.INI, HDALOG.TXT and HDAICIN.TXT and report. Thinkpad_X61_Debug_HDAICOUT.HDA

Error, to be removed

@MisutaaUrufu Today I tested if I could write to some PCI registers of VBOX 6.0.18 with INTELHDA.EXE. It was possible, new values even survived a VBOX reset. So I think the earlier tests I referred to where on an earlier 32-bits version, or my memory was mistaken altogether. Watler's Win.3x HDA driver can be used in VBOX (contribution of @UCyborg). Today I made a small discovery: after Reboot to MS-DOS, some MS-DOS players gave sound . Both mplayer versions remain silent, but Judas21C and Judas21D happily played their XM-files WITH SOUND! I think HDA2.DLL or HDAICOUT.HDA provided some verbs Judas21C/D didn't sent. Without loading HDA2.DLL in Windows, Reboot to MS-DOS gave no sound with Judas21C/D. With the MS-DOS-version of Craig Hart's PCI+AGP Sniffer I compared the HDA-controller registers in all situations, but they where all exactly the same, so no (HDA2.DLL-internal) PCI_quirks involved. So maybe Parallel's registers have RW-registers too ready for testing.

@MisutaaUrufu Testing is the only way to get somewhere with this driver, mplayer will take only a quarter to half an hour. I saw you´re a new member: don´t forget your input can be relevant for other readers! I don´t understand, what do you mean with 'TSR' and which setting you changed exactly? No modem = GOOD In the Parallel's User Manual I found three different Network configurations. So you may have four possibilities, included switching Network off. Thanks for the link. This is the 64-bit version, but as far I as know not compatible with Windows 10. Importing of your xml gives me an error only, importing the ini gives a widget-list that makes ABSOLUTE no sense for a codec. Better try Windows 7 with the High Definition Audio Utility, I believe you have one month free trial with Win7. Experimenting is partly a blind process, so just try please. I have been reading some Parallel 9x Forum-threads, they all complain about having no sound. Watler made an Win3x AC'97 driver too: Intel 82801AA/DB ICH AC'97 Sound Driver 10 (I have never tried it, but some people on the internet liked it, don't remember exactly). It's here: http://turkeys4me.byethost4.com/programs/ If HDA2.DLL is working you should hear about three medium-loud click's/pops. About that 'entirely custom configuration': the source code is included in HDADRV9J.7z (Delphi 2 ). If you want to test Watler's INTELHDA.EXE, it's inside AHDA17M (download is actually AHDA17O.7Z) on: http://turkeys4me.byethost4.com/files/

Good work! I will start writing a Thinkpad X61 specific version of HDAICOUT.HDA I understand your frustation, if you allow me a personal note: you can find my own Quest regarding HD-Audio here: https://web.archive.org/web/20180318132454/http://win3x.conforums.com/index.cgi?board=Pascal&action=display&num=1502071336 (I saw Watler recently published the first 8 pages of the Conforum-posts in a zip: http://turkeys4me.byethost4.com/files/?i=1) The driver HDA2.DLL has it's own set of verbs to identify the codec and give the codec some basic configuration. The goal of HDAICOUT.HDA is to sent specific SET-verbs to the codec if the general verbs are 'not enough'. You can find many (all?) verbs in a box under the nodules-Tab of INTELHDA.EXE. Advanced HDA-drivers, like the driver of the Linux ALSA project, have widget parsers onboard to identify all widgets and set (semi-)automatic a working configuration. Still these projects have many codec/board specific problems to overcome. HDA2.DLL has no widget parser. INTELHDA.EXE has one (as you already found out using the widgets Tab), but will report only. For testing purposes you can sent individual verbs to the codec, with the 'Immediate Command'-interface under the jds-Tab, or with the CORB-interface under the CORB-Tab. Afterwards they can be copied to HDAICOUT.HDA. You can try yourself (only the CORB-Tab will work in case of your HDA-controller). In a nutshell (you gave me a minute...): click button 'Corb reset', check the box 'Use Corb for Verbs', type $000F0000 in the box directly right of button 'CorbWrite' and click that button. The codec response you're supposed to get in the big box beneath button 'View Corb' should be the same as in HDALOG.TXT! Before a next verb, first click "Corb reset'. To get special values I always search first in the codec-datasheet (if available), in combination with Linux-sources for bug reports (ALSA, Hackintosh, InsanelyMac, Kolibri, FreeBSD and others). Most sources doesn't give full verbs, but only parts of them (their drivers work in that way, almost impossible to read for a non-programmer like me). On the level of the HDA-controller sometimes a patch is needed for HDA2.DLL to any make communication with the codec possible at all (@bmw's stage) or otherwise. One 8-bits register can be set to a certain hexadecimal value with pcipatchB. There are several way's to get PCI HDA-controller register values. First get access to the specific datasheet if available - scroll to the HDA-registers and start reading (and counting, the binary bit-values have to be converted to a hexadecimal value), and search for PCI_quirks in Linux sources. Another approach is to try MS-DOS players and if they are providing sound: read out the controller registers for changes (experimental approach). Be aware I have only 'worked' with a dozen HD-audio motherboards or so, and counted with direct access only with five.

@MisutaaUrufu For now I will give a response to your posts and some suggestions. MS-DOS has no quirks, 'PCI_quirks' are used in Linux-code to have a defined name for a PCI related problem. In case of HD-audio controllers quirks are for instance related to the so called "No Snoop"-mechanism. Did you try the version in Mplayer_dos.zip too? Besides: none of the four MS-DOS players I tested gave sound in Virtual Box 6.0 (Judas21c, Judas21d and two versions of Mplayer mentioned in this thread). HDAICOUT.HDA is ment to sent specific verbs if the standard verbs sent by the driver (HDA2.DLL) fails. As you can see in HDACFG.INI your Codec isn't identified yet. CODEC_VID=$1AB8 CODEC_DID=$0001 is not a known HDA-codec. Maybe a modem? Unless the codec is correctly identified, nothing can be done. In the first attachment of your later post the codec is identified as VendorID=6840 DeviceID=1. Still unknown to me, maybe a fake id. for Parallel's Virtual HDA-codec. Although HDA2.DLL is ment for Win.3x only, it's tested on Windows 98SE and Windows ME, I can't remember if I tested Windows 95/Windows98FE, but it's is likely to work if their are no Memory/IRQ-conflicts. Can you provide a link to the download page? In the past I used a 32 bits program, only compatible with Windows 7. I need it to open the xml-attachment in your other post. I am not an expert either, in my opinion nothing can be done on the codec-level until the codec is correctly identified in HDACFG.INI. This means that the so called "Immediate Command" communication-mechanism is not working with HDA2.DLL in combination with your HDA-controller. Try timings 1000 or 2000 (milli-second!), but I doubt things will change. Settings in pcipatchB will only work if there are RW (Read/Write) registers in your Parallel's VM-HDA-controller PCI-register. I am afraid that's unlikely. I have only tested Virtual Box: their VM-HDA-controller PCI-register is Read-only, so al values are fixed. You can try to write to the registers from Windows with INTELHDA.EXE. Just go to the pci-tab. If you double-click on a register, a dialog will be opened to give new values. If they actually do NOT change, that register is Read-only. You can try all the (four digits) register-entries. But first I would suggest to disable temporarily ALL devices, especially Network, except the bare minimum. Be sure in Sound the HDA is selected. In the User Manual of Parallel 16 I found there is an option for AC'97 too. Monitor HDALOG.TXT if lines containing F0 give any other response. For now I will not repond to your settings on the codec level. I think you will now understand why.

@bmw I really ment the value you found under XP! Just for the sake of experiment, and see if Windows will do anything with it. Today I had some spare time and liked to test another MS-DOS player, Mplayer, on my ´new´ H61-board. I googled around, but could´t find a download location until I came across this thread. The player inside mplayer_dos.zip is really nice, worked out of the box with CWSDPMI.EXE. I played my favourite testfile DRUMLOOP.WAV. But also a Youtube-MP4! Nice sound and good video. First the audio lagged behind, but after loading SMARTDRV everything was okay. In case you want to continue: here is the link to April 12, 2019. You can use CWSDPMI.EXE from JUDAS21C. Just unzip mplayer_dos.zip in some folder and copy CWSDPMI.EXE in the same folder were MPlAYER.EXE resides. Only for use in Real mode! https://msfn.org/board/topic/178295-audio-driver-for-realtek-hd-audio-hardware/?do=findComment&comment=1162272

@MisutaaUrufu Before I will try to answer your questions, please provide following information first: 1) What version of Parallels for mac you're using? 2) Is there a PCI-Card with yellow exclamation mark in Device Manager of Windows 95 OSR2.5? If it's there, is the Memory Address F0140000? And: no IRQ-conflict?

@bmw Just for the record: I assume pcipatchB=$3C10 did nothing? Was the new value reflected in INTELHDA.EXE? Which IRQ was reported by Device Manager for the High Definition Audio Controller in that case? Regarding USB audio: never used one. On MSFN "cheap $3" devices are mentioned, but @Ruthan reported one as "crap". I came across CMI6206 cards (only from China) for about $20.

@sweaterfish I assume you've tried pcipatchB=$7900 already together with HDAICOUT.HDA (Step 4)?

@jaclaz Today I did some more tests to find out which bytes of header+GUID of a LNK-file gives trouble with Grub4DOS. During this experiment I came across lzma! First I will describe the experiment, than I will give the print-screens. Prerequisite are 17 files in the range 4-20 bytes, I named them to their amount of bytes, with extension LNK. Most easy on a FAT-volume with fat mkfile. With write I wrote (without raw!) the 'right' amount amount of bytes of the header+GUID of a LNK-file to each file, always one less. It appeared that the gzip-error popped up only during writing 20 and 19 bytes. From the 18 bytes file down to the 13 bytes file, no writing problem, but with debug on there was a warning: Grub4Dos switched to raw, because of detection of lzma-data which couldn't be decompressed. From the 12 bytes file down to the 4 bytes file NO warning. Afterwards I'd try to read all files with cat --hex (without raw too): same problem with the 20 and 19 bytes files, like in my previous post about this subject. Same warning (with debug on) as during writing in case of the 18 bytes file down to the 13 bytes file. From the 12 bytes file down to the 4 bytes files no warning too (to fit on the print-screen I switched debug off earlier). the issue must be *somewhere* here: https://github.com/chenall/grub4dos/blob/master/stage2/dec_lzma.c It seems (to me) that the file format has not any fixed signature bytes: https://svn.python.org/projects/external/xz-5.0.3/doc/lzma-file-format.txt http://fileformats.archiveteam.org/wiki/LZMA_Alone so it is a mis-detection of some kind. I will try to read your sources, but I (almost) never cared about file-headers, so I have not so much to say about this subject for now. I have red the post, I hope someone will respond - on your post on the vol-command & label still no comments (when I have finished FATMKDEV.G4B, a generalization of my earlier RD2HD-files, I will report in that thread if I found new issues).

@Wunderbar98 I am very happy with your contribution, I am looking now for a way to use two quotes only in case of spaces in PATH1/FILE1, instead in all individual parts containing spaces. In FATCOPY.G4B version 0.3 (forthcoming!) using only two spaces gives undesirable results: the whole root of DEVICE1 is copied, I am afraid with the /s-switch things will be even worse. I have to anticipate too how potential users (if any) will try to use the command-line. If FATCOPY.G4B is ready, I will move on with FATMKDIR.G4B, FATDEL.G4B (both FAT-only) and FATLSDIR.G4B (for all file-systems supported by Grub4Dos). During my holiday this summer I made the first versions on my smartphone with Limbo Android/X86 (I had no PC around). I am not sure if FATREN.G4B is really worthwhile, but the Grub4Dos-program FAT gives the interesting possibility to move a file to another directory. With my batchfile-approach this could be generalized to all files in directory, or groups of files using "*"-wildcards. So very difficult to resist such a project (for me ). By the way, do you know a tool to make EXT3, EXT4 and ReiserFS partitions inside Virtual Box 6.0 on a VHD? So far I succeeded only with EXT2, and (unexpected) with Reiser2FS after I installed Suse 8.2 from an old DVD.

@bmw Well done! Indeed, last two digits of W21 are the one-byte value of 8-bits register 42h. Earlier you said you tried all values I gave you. To be sure try pcipatchB=$4200 once again. Your observations regarding last two digits of W21 are interesting, but I do not know what to do with this register. Should be Register 3Ch. The SB600 documentation call´s this register "Interrupt Line", a 8 bits RW register (so Read/Write!). The text is cryptic:"This register is used to communicate to software the interrupt line that the interrupt controller is connected to. It is not used by the HD Audio controller". I have no idea´s about this register (I am not a PCI-device programmer, even worse: I am not a programmer at all ). But feel free to try several IRQ-values with pcipatchB. You can also use INTELHDA.EXE to change the value on the fly by typing in new values (Only in RW-registers of course). Al values in HEX (register-address is in hex already)! If there is no immediate change regarding output of HDA2.DLL, maybe it´s following is a good procedure: boot Windows with HDA2.DLL active, change with INTELHDA.EXE a register value you like, Reboot to MS-DOS => Exit to restart Windows 98SE (like sweaterfish did) and look if anything changed in HDALOG.TXT. Also watch the IRQ-value of the High Definition Controller in Device Manager. I hope this will give any results, otherwise I think it´s better to look for another solution like USB-audio.

I am sorry I didn't make myself clear. I need a hex dump of the registers of 1002:4383. Should look like the PCI-tab of INTELHDA.EXE, but in a bit different fashion. You will have used the program pci32.exe. You have to run from a command-prompt following command: [PATH]\pci32 -D > ATIDUMP.TXT (not case-sensitive) I do not know where you unzipped the download. Say if you choosed location C:\PCISNIF than the command will be C:\PCISNIF\pci32 -D > ATIDUMP.TXT Below is the original information from my chipset, the dump is the second part (made in 2017 with an old MS-DOS version while using new PCIDEVS.TXT). Bus 0 (PCI), Device Number 20, Device Function 2 Vendor 1002h ATI Technologies Inc Device 4383h IXP SB600 High Definition Audio Controller Command 0006h (Memory Access, BusMaster) Status 0410h (Has Capabilities List, Slow Timing) Revision 00h, Header Type 00h, Bus Latency 20h Self test 00h (Self test not supported) Cache line size 64 Bytes (16 DWords) PCI Class Multimedia, type Unknown! Subsystem ID 76621849h Unknown Subsystem Vendor 1849h ASRock Inc Address 0 is a Memory Address (anywhere in 64-bit space) : FBFF4000h System IRQ 10, INT# A New Capabilities List Present: Power Management Capability Supports power state D1 Current Power State : D0 (Device operational, no power saving) Hex-Dump of device configuration space follows: 0000 02 10 83 43 06 00 10 04 00 00 03 04 10 20 00 00 ..ƒC......... .. 0010 04 40 FF FB 00 00 00 00 00 00 00 00 00 00 00 00 .@ÿû............ 0020 00 00 00 00 00 00 00 00 00 00 00 00 49 18 62 76 ............I.bv 0030 00 00 00 00 50 00 00 00 00 00 00 00 0A 01 00 00 ....P........... 0040 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................ 0050 01 00 42 C8 00 00 00 00 00 00 00 00 00 00 00 00 ..BÈ............ 0060 05 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 ..€............. 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ The first part is like the report you delivered. The program 'translates' the hexadecimal values with help of the database. But we need the hexadecimal values, to see if I can find any potential pcipatchB.

@jaclaz Thanks for the clarification of the blocklist command. I tried cat --hex --length=16 (hd2,0)284918+1 but no difference. See picture below, lines 2 and 3. In a file with the header of 4 bytes there was no problem reading with cat --hex. The next 16 bytes are the GUID according to https://github.com/libyal/liblnk/blob/master/documentation/Windows Shortcut File (LNK) format.asciidoc Here lies the problem, when I wrote the first 20 bytes to a 20 byte file with write : same problem as before. But when I tried this a second time to make a printscreen, I got Error 71 Attempt to write a gzip file. See picture below. The raw command seems to solve all problems, even with dd - I never used raw before. See second picture. First 3 lines to produce the file 20bytes.lnk, with header+GUID form a Windows Shortcut File. The later lines are for the dd-test, without and with raw. So you seems to be right that there is a connection with Grub4Dos treatment of gzip.

Thanks, point taken. I will make a new attempt. I tested on FAT and FAT32 so far, but NTFS gives the same results. Can you tell something more about the blocklist command please? The backslash is always provided by ls before a space, in my experience. I did some new test on NTFS, without spaces in Path/File and using TAB-autocompletion. I used two renamed IrfanView-lnk files, one from Windows 98SE, one from Windows 10 64-bit. Same strange output with cat --hex with different length´s. No difference. If I change first four bytes as you suggested, other bytes are looking fully normal now. For comparison I added the same amount of Lister´s HEX-views of the original files. @Wunderbar98 thanks for your comment. In Grub4Dos qoutes are taken, but starting only AFTER the first backslash. Combined PATH/FILE between qoutes is still a usefull hint, because I am working on a LFN-module to copy LFN´s in /PATH1/FILE1 to SFN´s in /PATH2/FILE2. I have made you nice picture of the possibilities. By the way, I found "read" case-sensitivity only on Linux file-systems I have tested. Further I have red that UDF should be case-sensitive too.