I am using DB Pro with vista. I have had a few issues, but I have managed to sort them out. First of all set dark basic to run as an administrator. You can do this by right clicking the dbpro exe file and editing it's properties.
To get dbpro debugger to work you need to copy MFC71.dll to
"C
rogram Files (x86)The Game CreatorsDark Basic Professional OnlineCompiler directory
I have not used DarkExplorer. I use XN Resource Editor, which will allow you to edit resources as well.
http://www.wilsonc.demon.co.uk/delphi.htm
The only problem is when you edit a dark basic executable, it destroys the executable ( under windows 64 bit vista SP1 ). I get the same problem when I use my home brew copy protection system.
There are some little know windows API function calls that allow you to edit the resources of an executable once it has been compiled. These are BeginUpdateResource, UpdateResource, and Endupdate resource. I used to use these with my own home brew copy protection system. It is unfortunately these function which I am pretty sure don't work correctly on vista. I looked on the net and other people were getting similar problems to myself, under windows xp. I tried to report the problem to microsoft, but I ran into the corporate wall of denial and dis-service.
My copy protection system works like this. If I want to protect a module within an exectuable, I inject a hollow resource of a fixed length into an executable. I call this block a cyclic redunancy omission block ( CROB ). I mark each end of the block with the word CROB. I add a special string to the executable to make the executable unique with a unique licence key usually a GUID. I then create a hash of the executable for every byte, except the bytes within any CROBs, there might be more than one.
I then pass control to a separate program - this program check's that the end user has a valid licence, it can do this with an internet check.
I then generate a random string of characters to insert inside the CROB. The random number generator is seeded using the result from the hash function and the licence key. I then encrypt the garbage using a special key within my dll and store the encrypted garbage back into the crob in the executable.
When your dll loads you can load the resource of the executable that it is under. Therefore you can get the licence key, the information inside the crob and you can recalculate the hash function again. It is therefore a simple process to recreate an encrypted string of garbage and check that it matches the string inside the CROB. If the strings match your plugin is licensed if it doesn't it's not. Depending on the encryption algorithm you choose you can make it hard to crack this encryption. If you encrypt the garbage string remotely using a public private key system you can make it hard to fake the CROB string ( although I don't don't do this as it means running a server ).
The executable is locked because you can not change any part of it.
The added advantage of this copy protection system is that if one byte of the executable changes or a byte inside the crob changes; the copy protection is invalidated. This means that if the executable is attacked by a trojan it will trigger the copy protection system.
The disadvantages are that it will not work other copy protection systems that add a stub of code to an existing executable.
Anyway I thought I would make this technique public, so people can poke holes in it.
You could also store the licence keys on the internet so that an end user or os software could check to see if an exe contained valid modules.
Anyway it doesn't work any more as the update resource API is broken.
If you want to track down missing dependencies I find Depends.exe to be a very useful tool ( available from microsoft ).
Jack Taylor
