Hi,

I'm having issues with ProgDVB 5.15.5 and a BDA driver I programmed myself. Now since I programmed my BDA driver strictly to Microsoft's guidelines, would it be possible to at least add an option to make ProgDVB behave BDA-compliant? I know the current behavior is needed for e.g. TechnoTrend's non-compliant drivers, but now that Microsoft is starting to support DVB-S/S2, we'll likely see the number of BDA drivers adhering to their guidelines increase.

The issues are:

1. Symbol rate is passed in kbaud to the driver (e.g. 27500 for 27,500,000 symbols/s). However, the BDA specification states that the symbol rate is to be passed in symbols per second:

http://msdn.microsoft.com/en-us/library ... S.85).aspx

2. The DVB-S2 modulation types are passed incorrectly. No matter whether you select NBC_QPSK or NBC_8PSK, ProgDVB passes the value 23 to the driver, which means 8VSB and in fact is completely wrong (but used in TechnoTrend's "hack" driver). Could the correct values be put in there? QPSK=20, 8PSK=27, NBC_QPSK=31, NBC_8PSK=32. You can leave 8VSB=23 as an option for TechnoTrend's hack...

3. Also how about offering NOT_SET as a modulation type for drivers which can _autodetect_ DVB-S/DVB-S2 modulation? FWIW, the TechnoTrend budget S2-3200 card is perfectly capable of that, only noone (but me;) bothered to implement that in a driver...

3. DiSEqC(TM) support. I'm afraid the Microsoft specification for this is not public yet. For the time being, would it be possible to use the TunerRange parameter with values coherent to the others? I.e. -1 = NOT_SET, 0 = NOT_DEFINED, 1 = Position A, 2 = Position B, ...?

If you need to test these changes and happen to have a TechnoTrend Budget S2-3200 card with STB0899 Cut 3.2 (marked "C2L") on it, I can provide a BDA driver which is not only compliant but also works considerably better than the junk TechnoTrend bothered to put together...

Reads very interesting, indeed.
Might lead to a new general BDA device for ProgDVB, at least...

Perhaps better contact Prog by e-mail.
To be found at the bottom of each page here.

BTW, may be a bit off-topic, but do you see a chance, to use BDA drivers in Win9x, somehow?
I did not yet find a single device which would work this way...

Juergen wrote:BTW, may be a bit off-topic, but do you see a chance, to use BDA drivers in Win9x, somehow?
I did not yet find a single device which would work this way...

Hmm, the DirectX 9.0c runtimes do add BDA components to Windows 98, 98SE and ME - but those are from 2004, and BDA was in a terribly buggy state back then...

I don't think I've ever tried installing one of my BDA drivers on Windows 9x/ME, and I'm afraid it'd be a rather frustrating experience seeing how bugged that old BDA implementation is...

Well, some basic BDA support in fact came with DirectX.
But AFAIK it's limited to sound card components. To be found on the device manager in safe mode here.

Also can't find any unofficial update, like from
http://www.nandlstadt.com/win98sp.htm
English pages, still back 'a bit':
http://exuberant.ms11.net/98sesp.html

But from my point of view, BDA is the only really important issue I am still missing completely, compared with 2k and XP...
Basic problem on some devices I've tried on, drivers simply would not install.
Even manually, .inf files manipulated, no success yet.
Seems, BDA drivers like to verify the OS version.

Basically my fault, as I am not a programmer...

Did not mean to go to far off-topic here, but I just thought, it might be worth a try.
Wishful thinking...

Juergen wrote:Even manually, .inf files manipulated, no success yet.
Seems, BDA drivers like to verify the OS version.

At least mine don't. The problem is that Windows 9x/ME only "emulates" a Windows NT kernel, and the emulation is not complete, only some kernel APIs are supported. The BDA driver you were trying to load might import kernel APIs which are not present in the emulated Windows 9x/ME kernel.

If you have Visual Studio installed, you could examine the BDA driver binary for the APIs it imports with the command-line command "dumpbin /imports <driversysfilename>". Then you could search the Windows 9x/ME kernel emulation for these functions (I think the file is NTKERN.VXD, but I'm not sure). If you find functions in the BDA driver which you cannot find in NTKERN, you know why the driver doesn't load.

I've taken it upon myself once to port back a driver (RASPPPOE) from Windows 2000 to Windows 9x, and it was rather painful having to find alternatives to the missing kernel APIs... Aside from the fact that some things were so broken that I spent nights debugging through Windows code to figure out why it failed and how to work around these bugs...

Thank you for explaining.

Hope, I will find enough time occasionally, to play around with the VS stuff.

My NTKERN.VXD shows 4.10.2224 in properties, extended show 4.10.2225. File change date October 24 / 2004. Don't really know if it came with the unofficial service pack 2.1d, an earlier version of this or from some MS update. Originally it was .2222, of course.

Been using RASPPPOE for years, should have saved me quite a penny on connection fees, during the analogue modem age...
Nice one,indeed.

However, if creating a new BDA device, it would probably be a good idea, not to involve the latest VS 2008, by this keep open the door for a later use in W9x.