Hi everyone:
Please bear with me as I haven't done asm for over 10 years! My latest endeavor is to convert an old 16-bit asm code to run on a Windows Vista/7 machine. I will have to write most of the code using C/C++ and the Visual Studio compiler, but what I'm curious about are the IN and OUT asm commands. The code needs to communicate with the hardware directly using I/O.
Is it still allowed from a user-mode code under Windows 7 (not running elevated)?
The problem you will run into with IN and OUT is that protected mode does not allow that form of direct hardware access. For reasonably normal tasks there are API functions and for less critical tasks you can do it with file IO but if you want to access hardware directly, you will need a driver and on Win7 that is a problem in that all drivers must be signed by Microsoft.
Oh, I see. Thanks for the explanation.
dc2000,
What hardware are you communicating with, and thru which "ports"? It can change how to approach the connection.
farrier
I need this to access some parameters in computer's BIOS.
Quote from: hutch-- on July 03, 2012, 01:15:43 PM
...you will need a driver and on Win7 that is a problem in that all drivers must be signed by Microsoft.
Hutch, just curious, what would be the cost of such signature for a device driver?
http://www.pagetable.com/?p=12
QuoteYou do not understand the true cost for driver maintenance. Not only do testers pay from $250 for each driver SUBMITTAL, (use to be $2500 for a long time) we pay the same price for each operating system. Now multiply this for each time a driver is updated. Multiply this for each time a driver has to be re-deployed into the field and technical cost. Now multiply this times the cost of lost customers because they will not wait for you to get an updated driver signed even if its a few days away.
You do not understand what its like to read through the enourmously large 80+ pages of a legal aggreement to have a driver signed.
Quote from: dc2000 on July 03, 2012, 06:29:37 PM
Hutch, just curious, what would be the cost of such signature for a device driver?
Nothing if you create your own certificate that is shared with the signed driver. Using the driver requires to install the certificate on the target computer.
The corresponding tools are part of the WinDDK.
If your version of Windows will run DOS apps, then depending on which I/O ports the DOS app is accessing it may run under Windows without problems.
>Nothing if you create your own certificate that...
I was under the impression that the later versions of Windows require certified drivers (certified as in tested for reliability and compatibility, same idea as the old WHQL tests), and I doubt that the certification is free.
thank goodness for XP !!!
Quote from: MichaelW on July 03, 2012, 07:08:54 PM
>Nothing if you create your own certificate that...
I was under the impression that the later versions of Windows require certified drivers (certified as in tested for reliability and compatibility, same idea as the old WHQL tests), and I doubt that the certification is free.
I've used this method for Vista x32, which also requires signed drivers. A quick test on my Win7-x64 machine shows that this method won't work anymore. However, if the TESTSIGNING-boot-option is enabled, it works well...
there may be an option somewhere to disable "require drivers to be signed"
let's face it - you have to be able to test unsigned drivers, somehow :P
but - that may not help for general distribution
here's one way
(http://static.raymond.cc/images/disable-driver-signature-enforcement.png)
here's another
http://www.ngohq.com/home.php?page=dseo (http://www.ngohq.com/home.php?page=dseo)
if you can do it with F8 at boot, there is probably also a switch that could be added to boot.ini :t
There is no way to permanently disable the driver signing requirement on 64-bit versions of Vista or 7 through the registry or other simple settings. You must disable it each time you boot.
Some feel that it is an attack on free software. Certainly it makes it much harder. There used to be a signed driver whos only purpose was to load unsigned drivers, but Microsoft revoked its certificate under the plausible excuse that is decreased security (after all, malware could simply ship with that signed driver.) I recall the revocation of that certificate broke the popular Daemon Tools CD/DVD emulator.
More on the topic of the OP, however, I question the need to IN/OUT. If a userland application needs direct access to the hardware then its doing it wrong. A stable multitasking OS requires a layer of abstraction to prevent userland applications from arbitrarily messing around with the hardware. If this is a one-off operation, then provide a bootable disk image. If you need to do it often then provide a driver. A certificate can be picked up for under $100/year. Not cheap, but not going to break you either. If its for free software.. a few "donations" is all you would need to pay for it.
Quote from: Rockoon on July 06, 2012, 10:29:43 PM
There is no way to permanently disable the driver signing requirement on 64-bit versions of Vista or 7 through the registry or other simple settings. You must disable it each time you boot.
You can permanently enter the test mode:
Bcdedit.exe -set TESTSIGNING ON
This removes the need of WHQL-certificates.
Unfortunately a text appears in the bottom right corner of the Desktop: "Testmode,..."
there is always a way :P
seems to me that a little program that runs at boot could disable the "feature"
as for using in/out in user-mode programs, i am not sure i agree
back in the days of DOS, i used to write programs that used in/out and set interrupt vectors all the time
i can understand the need for chaining vectors, of course
the question here is security, i suppose
but, i don't see a lot of attacks coming from the serial or parallel ports - lol
as a hardware engineer, i would often like access to these ports
so - i guess i have a "non-standard" view of the issue
Posted by: dedndave
« on: July 07, 2012, 01:44:19 AM »
Quotethere is always a way :P
That might be or not. The trick is: Your usual Windows application is running in ring 3 - and that's the a.. end. All hardware accesses are virtualized. Only ring 0 programs have unlimited hardware access.
Gunther