Page 1 of 1
Posted: Fri Sep 04, 2015 9:13 pm
The Inp32 and Out32 functions are equivalent to the IN and OUT opcodes in x86 assembly. It's great that you have made these available with your special driver, as I have found in Windows XP that these op codes don't work (I think because XP blocks these to prevent possible system damage, because they are such powerful op codes). But that's not the only op code that XP prevents the use of. It also prevents the use of the INT op code for calling interupts. I would like your next version of InpOut32, to have a function equivalent to the INT op code, so that I can do some very powerful programming, that involves switching graphics mode at the hardware level (to force VGA mode for example, whether Windows wants it or not, it will be dragged "kicking and screaming" into VGA mode, because the CPU can't refuse a direct order given to it). This will allow me to make oldschool type games, directly in Windows, without needing to use DOSbox, and will at the same time, allow me to continue to use 32bit code for the majority of the programming (something that a true DOS program can't do).
Re: Feature suggestion.
Posted: Fri Sep 04, 2015 9:18 pm
Sorry, but I didn't write InpOuyt32, I only ported it to x64 Windows. So I wont be making another version. Mainly because I cant sign the drivers so its pointless anyway. On XP you could do this yourself (the drivers dont need signing) and your welcome to do that, but dont expect anything new from me in a hurry because it just wont work on Windows vista or later without the ability to sign the drivers.
Re: Feature suggestion.
Posted: Fri Sep 04, 2015 11:47 pm
phil wrote:Sorry, but I didn't write InpOuyt32, I only ported it to x64 Windows. So I wont be making another version. Mainly because I cant sign the drivers so its pointless anyway. On XP you could do this yourself (the drivers dont need signing) and your welcome to do that, but dont expect anything new from me in a hurry because it just wont work on Windows vista or later without the ability to sign the drivers.
Are you aware of any other driver that (like inpout32) was created solely for the purpose of bypassing Windows XP (and above) protection against low level functions, so as to reenable them for programmers? If such does exist, is there one that supports calling interupts?
Also, from my understanding, getting a driver to be signed by Microsoft is a very expensive (money wise) process. As a result, Microsoft I believe intentionally left open a loophole for people who are developers to test drivers that they create. And I believe that this testing loophole method can also be used by end-users to run a driver not signed by Microsoft's certificate. I think the developer driver testing loophole works like this. Using a program that comes with the Windows SDK called makecert.exe you can create your own self-signed certificate. Then, using that certificate you can sign your own driver. You will also need another program that comes with the Windows SDK (I forget what it's called) in order to take this certificate and use it to sign the driver.
Now because it wasn't signed by Microsoft, the Microsoft certificate that comes with every installation of Windows will not work to allow the end user to install the driver on their PC. As a result, the end user will need to have a copy of the certificate file that you created, along with your self-signed driver file, in the ZIP file that you distribute to end users. Fortunately, having an end user install the certificate is a much simpler process than self-signing your driver, and does not require the Windows SDK. I think it just requires doubleclicking on the certificate file, and when it says that this certificate is not signed by a known certificate authority (because it was self-signed, and you aren't the Verisign company or Microsoft), it will ask you if you want to install it despite the fact that it can't be verified. At this point, you tell it to install the certificate anyway. It's as simple as that for the end user, to install the certificate that will be needed for the end user to use your self-signed driver. So provide these instructions in a readme.txt file that will be in the ZIP file along with the driver file and the certificate file.
Re: Feature suggestion.
Posted: Sat Sep 05, 2015 1:45 am
1. I'm not aware of anything like that - not to say it does not exist, its just not something I am particularly into. I ported input32 to x64 for one reason, 12 years ago or more and haven't used it myself for about 8 years!! Its still here to benefit others but that's about it.
You are partially correct about the self-signed certificate for drivers but (and its a bug but) you have to run windows in test mode. In XP this was easy. On later systems you might find that running in test mode means other things don't work. For example, in test mode, I believe that HDMI content protection wont work, so no blu-ray type playback for you! I've no idea how many other functions this might prevent but its certainly not as simple as just installing a certificate!
And from my experience with certificates in my mouse software (not driver related), many users these days don't trust any old certificate, especially if it can introduce drivers that bypass kernel protection. These days people are much more paranoid about security!
I had to purchase a software signing cert - but unfortunately this is not valid for drivers. To get a cert that can sign drivers, you need to a) be a registered company, b) be prepared to spend >$300 a year! Personally I don't like that, but at the same time, I can see why Microsoft did it.