Under NT, "user-mode" code (ie: applications written by mere mortals) is not allowed to access hardware directly, hence when your application attempts to execute an I/O instruction you get an exception. The idea is, of course, that hardware resources are things that no application should just take over at will, instead it should be up to the operating system (and its drivers) to arbitrate between different apps requests to use those resources.

That's the theory. Turns out that the NT kernel maintains a map of I/O port addresses that each process is allowed to access, and for your apps that's normally set to "none". But we can tell NT to use a different I/O Permissions Map (IOPM) for our process and thereby gain access to the ports. This approach is of course very naughty from a disciplined OS standpoint, so not recommended for widely distributed commercial apps. But for those times when you just need to hack on some hardware, who has time to write a proper NT device driver?

The only problem is that user-mode code is not allowed to execute the kernel functions to change the permissions map. The workaround for that problem is to create an NT driver (drivers have sufficient privileges) to twiddle the IOPM at the request of your app. Just such a driver, giveio.sys, has been floating around the net since '96, authored by Dale Roberts in conjunction with a May 96 Dr Dobbs article.