I use win98 to test a prog that will, later,
use an OS that allows direct I/O.

win98 does allow the use of direct I/O, however,
some ports are trapped and using those ports
trigger ring0 code which than reads some other port
and that interferes with the hardware I'm using.

(In normal operation, win98 doesn't use that 'other port'.)

Currently, I have to rewrite my code so that it
runs from VXD, but would really like to un-trap
those ports. How? Anyone done this?

I know that TSS has an I/O bitmap, but that is optional, IIRC.
Does win98 always use it? Any examples of changing the TSS?

Thanks

Posted on 2009-12-09 04:04:06 by aleksaZR
You can use a ring0-hack to enter ring0 without VXD and then enable all ports...

But really, why develop/test on a Win9x machine?
Posted on 2009-12-10 04:10:47 by f0dder

You can use a ring0-hack to enter ring0 without VXD and then enable all ports...

But really, why develop/test on a Win9x machine?


Because it's harder to do ring0-hacks on a real OS? :)
Posted on 2009-12-10 05:40:14 by Scali
If by a real OS you mean one that makes it next to impossible to gain direct access to hardware (eg audio acceleration under Win7) :P
Posted on 2009-12-10 07:40:23 by Homer

If by a real OS you mean one that makes it next to impossible to gain direct access to hardware (eg audio acceleration under Win7) :P


More like: an OS that only allows (trusted) device drivers to access hardware directly, not user programs.
Windows 7 doesn't make audio acceleration impossible, they just removed the acceleration from the standard implementation of the DirectSound interface.
Alternative audio interfaces such as OpenAL or ASIO have no problem accessing audio hardware directly. And Creative's ALchemy is an alternative implementation of DirectSound which also uses hardware acceleration.
So impossible? Not at all. Just the end of DirectSound as we know it.
Then again, hardware-accelerated audio really isn't a big deal these days. I have an onboard chip from Analog Devices which can do 5.1 audio and encode it to a DTS stream in realtime, all in software, and I don't notice the performance suffering from it. So I'm not all that bothered by the lack of hardware acceleration. Heck, for the first time in ages, I don't have an actual soundcard anymore. Normally I used to have a Sound Blaster or something, even if I did have onboard audio. There's just no need anymore. Quality and performance of onboard chips are just fine.
Posted on 2009-12-10 07:57:47 by Scali
Yeah thats true - does it work on Win7, and in particular, does it work on 64 bit Win7?
Posted on 2009-12-10 08:17:41 by Homer
I only use 64-bit Windows these days. Both my Vista and Windows 7 installation are 64-bit. Aside from that I have both 32-bit and 64-bit XP installed.
Nothing much has changed between Vista and Windows 7 as far as I can tell. I just installed the Vista drivers in Windows 7, because there were no official Windows 7 drivers released, and they just worked. I have three devices with ASIO support (a Zoom G9.2tt, Pod X3 Live and an E-mu 0404 USB), and they work. OpenAL also works, although my onboard chip doesn't allow hardware acceleration.
My brother uses a Sound Blaster X-Fi in Windows 7 64-bit though, and as far as I can tell, it works fine... I assume it has hardware acceleration enabled.
Posted on 2009-12-10 08:24:36 by Scali
I have changed my mind.

I'll do all my tests from VXD.
That way I can also do CLI and be sure
that nothing interferes with my tests.


BTW:

I wrote a VXD to change the I/O bitmap.

When I exit my prog and start it again,
the table is not re-initialized by windows.

What, all progs use the same table? If so,
accessing the ports from ring0 is the safest bet.


> But really, why develop/test on a Win9x machine?

Because my main comp does not have dual PATA ports,
and the test comp is slow for anything else.
Posted on 2009-12-10 16:54:02 by aleksaZR