At some point, I'll try dumping all the w10 infs and look at it properly.

Why? Because all the guids and ven/dev ids and the device/subsection reg quirks will be in there since 10 supported the entire era and it is certain that the guids won't overlap anything.

Your driver won't support the quirks, but at least knowing that x behaves differently might help when someone inevitably tries it.

For various reasons I am using PCI_CC\0403 as the only device ID in the inf, and then reading the PCI vendor and device ID from config space to apply controller specific quirks. This is because most of the controller quirks require reading & writing to config space anyway, so there's no point in storing it in the registry keys, and also there's no way for the PnP Manager to read a codec VID/PID at driver install time because the driver is monolithic and not split into controller & codec(s) on the HDA bus like the Universal Audio Architecture.

Maybe it's possible on 9x to create a bus from the controller driver and make codec drivers attach to that but R. Loew couldn't get that to work and I'm not as smart or experienced. In the future I should still move all of the codec state into its own class to allow for multiple codecs on 1 controller like with a laptop in a docking station. This would also allow using a config script like the Watler's driver instead of depending on the very basic node parser.

2k used the same drivers, so I assume there's a way.
Then again, the 9x nvidia drivers are one giant sys vs several dlls on the nt branch.

2k also uses WDM drivers, true, but the HD Audio Bus architecture was backported from XP in KB888111 requiring a new sysaudio.sys and portcls.sys which R Loew could never get to work on 98se even with his WDMEX patching up the missing imports. The Toaster driver sample from the Windows 2000 DDK (the example for creating a bus) does not work in 98 either and I don't know why. Believe me if I could have backported the existing driver that would have been a Lot simpler.

Video driver architecture is completely different between 9x and 2k, and 9x drivers still need to have a 16 bit portion that handles GDI. But now anyone who wants to try to implement that can use all the code from JHRobotics' SoftGPU project.

I'm pretty ignorant, but as I understand from what you said, it's not possible to separate the hda bus from the codec for some reason.

Bus as in the literal bus like pci and isa are a bus? Or some logical bus?

HDAUDBUS.inf
Class = System
ClassGuid = {4D36E97D-E325-11CE-BFC1-08002BE10318}
%HDAudio.DeviceDesc% = HDAudio_Device, PCI\CC_0403
%HDAudio.DeviceDesc% = HDAudio_Device, ACPI\CLS_0004&SUBCLS_0003

HDAUDIO.INF
Class=MEDIA
ClassGuid={4d36e96c-e325-11ce-bfc1-08002be10318}

No actual devices in here. Seems like the inf equivalent of a header file.

HDAUDSS.INF
Class=MEDIA
ClassGuid={4d36e96c-e325-11ce-bfc1-08002be10318} Same as above.
Bunch of dev/ven, but not as many as I'd expect

I don't think the few GUIDs in your inf matter - they're all repeated in multiple infs in win11 so I think they're for a group thing.

One interesting thing - which seems to line up with the Watler's driver is the override verbs.

eg:
[HdAudModel_DellPrecision380.HdAudInit]
HKR,PinConfigOverrideVerbs,NumVerbs, 0x1,20,00,00,00
HKR,PinConfigOverrideVerbs,0000, 0x1,f0,1c,87,00
HKR,PinConfigOverrideVerbs,0001, 0x1,00,1d,87,00
HKR,PinConfigOverrideVerbs,0002, 0x1,00,1e,87,00
HKR,PinConfigOverrideVerbs,0003, 0x1,40,1f,87,00

Presumably that correlates to his - and therefore might be reversable for people to configure his better.

Maybe this new driver deserves its own topic?
WDM drivers have nothing to do with Windows 3.1x which this topic is about...

Read the last line.

Possibly discovered something useful for this driver.

That said, I agree

I made a new topic here for my windows 98 driver.

To answer the other question, yes HD Audio is a bus, the controller drives a low speed serial bus which connects to either audio ADC/DAC or modem codec chips. AC97 was also a bus like this which could have multiple devices (often software modems installed in the AMR or CNR slot) and this could be problematic because the controller and codec both had vendor specific Quirks and extensions and this all had to be covered by one driver for all combinations. It's not even possible for Plug & Play to see the ID of the codec(s) with no driver loaded. This meant that Realtek and Analog Devices and Sigmatel and others made their own driver packages with special features and you often had to try several to get one working. Since everything was closed source there was no easy way to tell without trying to use it either.

For HD Audio and the Windows Universal Audio Architecture, the functionality was split so separate drivers could handle the controller and bus, and each codec. Windows could then support the controller and let vendor specific drivers handle only the codec and Plug&Play would be able to find the right ones. But this architecture was never backported to 9x since it was already 2004. For Winmodems this was also pretty pointless since again it was already 2004 and there was never a separate slot for HD Audio modems like for AMR/CNR. They were occasionally used on laptops I think.