Donot lie, I have tested my new ldr install over your new ldr. Its working but as administrator. Try my new posted ldr. But paymyrent posted image installed as user not administrator. I have updated that too. Wait and see my next update.
Dont lie? What am I lying about...rofl. You make no sense. I was attempting to give you advice...if you think that I am lying to you then you have no idea how the windows file system works... ROFL!!! Why would I waste my time telling you something that was untrue. lol.
Well, you already said your app uses GUID paths in your thread.... If you were to use GUID paths you would know that when you use a GUID path, you dont have to mount the SystemVolume every time you install or unintall the loader file. It is just a much cleaner way of doing things. Remember that from your thread? ...and you have the audacity to call me a liar...rofl...look in the mirror buddy. EDIT: I have no wish to make you look bad, but when you point fingers at me like I am lying to you when I am just trying to help you...then I no longer care.
Yes my new posted ldr take ownership of the your ldr and overwrite it but only as administrator. Check my new ldr
Well, I am glad it works for you now then... I had assumed that the manifest in your app was working fine in prior releases (if you app's manifest is working fine, then your app should automatically request admin access every time it is run, and admin privileges should not be a problem) so you would not need code to ensure your app has Admin privileges (unless the user running it is not logged in with Admin privileges and can somehow force the app to run). I did not know you had issues with your app not gaining the appropriate Admin access (as that could be a reason that you cannot gain access to the loader file I guess). ...but the real trick is getting it to work with GUID paths.
But if HotCarl donot mind, I checked HotCarl ldr with my ldr in my system, his one take more time to install than mine. Edit : Ok I will try implement GUID path and will check what advantage it holds in future release.
Build and use a version that uses GUID paths, then use the version that does not. It is faster because you dont have to look to see if the system volume is mounted, then find a free drive letter, then mount the drive... Then after installation unmount the drive (if it was not already mounted)...etc...etc...etc. It is a little faster, and you dont have to worry about mounting/unmounting anything or finding a free drive letter (which all take a little time and processing to do). It is not required, it is just a faster, cleaner way to do it. EDIT: Of course our programs will take different amounts of time to install because they are different programs...coded differently. You need to compare the same program with it's self (after modification) to see any gains in efficiency and speed...
the process takes longer with his loader because he actually checks to see if everything was done properly...
Well, that is true. The install may take a little longer, but that is because my version of O7A checks to make sure the proper product key was installed (after the key is installed, my app compares the partial key in the system with the partial of the attempted key it just tried to install to ensure they match), it also checks to ensure the certificate is installed, and the loader file as well...so all that does take a little longer, but the end result is that the user will know if everything was installed properly (or not) because the program will be able to tell. It will also try a different method to install something if the first attempt did not work. I sacrificed a little speed to be able to be more certain that the program will do things correctly...and know if it has done something correctly (or not).
...speaking of you application, when are we going to see a release??? It's gotta be close to being ready.