My exe depends on ntdll, user32 and kernel32. I save these dlls as a local copy and change the first letter as "V".
I then edit the exe's Import dll name as Vernel32.dll from kernel32. The application works fine by loading vernel32.dll in local space.
Next i edit the exe's import dll spec as vtdll as ntdll, the process loads vtdll from local, runs its code and throws an _stackhash exception on vtdll instructions.
I need this for developing my appliction to bundle all windows dependencies. Does any body have any idea, Why ntdll cant be run in local space.
No! You cannot try to replace ntdll. It is mapped by the kernel into every single process, probably before any of your code is even loaded. It has an intricate connection with the kernel. It knows all the correct system call numbers. Try using ntdll from NT 5.1 and it will crash on NT 6.1. ntdll hosts the system call entry and exit code. The kernel-user callback dispatcher code. The thread start function which the kernel knows the address of. The user exception dispatcher. The user APC handler. I could go on, but I won't.
I don't see why you're trying to "bundle" these DLLs with your program. There is no way a Windows install won't have these DLLs. And that's ZERO chance for ntdll.dll since I don't see how without the session manager and CSR you are going to run your program in the first place.
I find the idea to "bundle" system DLL as not a good idea.
First of all it is illegal to redistribute this DLLs together with your application. Seconds you should understand that a DLL can create some global objects and the usage of two copies of the same DLL (vtdll.dll and ntdll.dll) can not work. You don't wrote how you modified imports of the dlls. If you do it on the disk it is illegal and moreover it break the signature of the files (open file properties of any of the dlls and look at "Digital Signatures" tab).
If you do want to experiment with different copies of system dlls you can better use DLL redirection (see http://msdn.microsoft.com/en-us/library/ms682600.aspx) through creating of files with the name myapp.exe.local where myapp.exe is the name of your application. It can be required to delete some entries from HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs to do this. You should understand that your computer will run slowly after this and I recommend to make such experiments better inside a virtual machine which you can easy restore if it will be no more booted.
Thanks for the information. It helped me to do a research on it.
I am not bundling the dlls for my own application. I am doing it for existing applications to provide a windows cross platform independence solution.
I tried the dll redirection technique which you have posted, with all applications.
It works well with all dlls except NTdll and User32.dll
User32.dll:
It loads user32.dll from local space only and not kernel space. I confirmed it. But on executing its instructions, it results in the null address access exception (c0000005) with fault module name StackHash_5964
ntdll:
The application on booting, it loads ntdll from system32 and again loads ntdll from local space, which may cause the error as you said (global object sharing violation)
This happens only for ntdll and not for user32.dll.
Is there any way we can make load ntdll once(only form local space) and avoid the errors caused by user32.dll in local space.
I tried the references sent by you and here are the results.
User32.dll
I couldnot build user32.dll having these below functions.
IsThreadDesktopComposited = user33.IsThreadDesktopComposited,
User32InitializeImmEntry = user33.User32InitializeImmEntry
It produces a linker error (Unreolved external symbol "IsThreadDesktopComposited")
Hence i left 100 such functions out of 800 functions in user32.dll. The DLL was built finally.
I then placed the dll in local space along with user33.dll. On running the application, it says the 100 missed functions procedure entry points are not found.
Ntdll.dll
I tried removing known dlls. But its inacccesible for modify or delete operations. I could just read. I am the admin and ran regedit as administrator.
Is it possible to do such implementatipons for ntdll or user32.dll.
I guess, am coming with repeated times.
Thanks for all your help.
But, If you have any other ways or any suggestions you can make, that would be grateful
Related
I'm struggling to find any method that works with current Unity.
This for a conventional Windows build (not a Windows Universal via VS).
So, there's the separate data, dll, etc files of a build: how to create a civilian-usable "single exe" for Windows, with current Unity??
As said afaik this was actually always the case.
See e.g. Windows standalone Player build binaries to see a list of resulting output of a build. It exists back until version 2017.2.
So the short answer is:
It is how it is. You will always get multiple files and the data folder as output.
What you can do however is using a pack tool which simply packs all your folder content into one single exe file.
One example is Appacker
=>
BUT unfortunately there is one known issue: Windows Defender recognizes it and every exe created with it as malware. The reason for that is actually mentioned by the author in the link
Spoiler: A self-extracting .exe file? Windows Defender hates that trick!
So either with this tool or any similar one there is no real way around that except you need to trust the tool and your users need to trust you ^^
(The icon is also only used for the process window, not for the exe file itself ^^)
The long and correct way would probably be to create an actual installer for your final app which is then allowed to extract all the files to a certain location.
So in the end the user anyway will again have an exe and according data and dll files e.g. in the Programs folder but get a registered shortcut to the Start Menu which is just how any other application on Windows usually works like.
Just to add to the answer.
In 2020 if it's a game you should just use Steam. Making auto-update way easier for your users.
https://partner.steamgames.com/doc/gettingstarted
I downloaded MikeOS and I ran his OS through Oracle VirtualBox and I thought it would be fun to tweak the OS a bit by adding programs/features etc.
So I modified some code, and I know the code is right because there were no compiling errors.
Anyway once the OS was modified, I downloaded MagicISO so I can make my own version of an ISO file to put the modified OS on.
However each time I try to boot up my ISO VirtualBox says "No Bootable Medium found!".
Am I turning it into an ISO wrong? Here is how MikeOS is formatted:
http://prntscr.com/37vchg
What I did was, I modified the "programs" folder with my new code then I copied everything in the folder shown in the screenshot above.
I pasted it into a new folder on the desktop called "MikeOS(modified)". I then right clicked and turned that folder into an ISO. Did I do something wrong?
Thanks!
PS: I can't add pictures because I need 20 Reputation.
"So I modified some code, and I know the code is right because there were no compiling errors."
Not sure what you mean by your code being "right".
"No compiling errors" just means your syntax was correct and all libraries, etc, were available. It doesn't mean your code is logically correct.
"However each time I try to boot up my ISO VirtualBox says "No Bootable Medium found! Am I turning it into an ISO wrong?"
Yes, you're doing it wrong.
Any bootable disk, be it floppy, hard drive or CD, requires a boot block to be present on the bootable media. The boot block is hidden from normal user inspection.
When you rip a CD (or whatever) all you're doing is grabbing data files off the media which may include jpgs, exes, dlls, sys files, and/or whatever else you might have, but doesn't touch the boot block.
In your case, you had all your data files, some of which you modified, and then burned them to a CD. It may LOOK just like the CD you ripped, but YOUR CD doesn't have the boot block, so it won't boot - as you have now discovered.
To fix your problem you need to get a boot block image (or as magic ISO calls them, a "boot image file") and add it to your CD composition and THEN burn your CD. Then your CD will be "bootable".
There's a few ways of doing that, and I won't go into that, but look under the "tools" tab of magiciso to get you started.
If I compile a script for distribution as a standalone exe, is there any way I can store settings within the exe itself, to save having to write to an external file? The main incentive for this is to save having to develop an installation process. I only need to store a few bytes.
Also, can resources such as images be compiled into the exe?
Using alternate data streams opens up a can of worms so i wouldn't go that way. Writing back config data into the exe itself won't work as the file is locked for write access during execution.
What i usually do is to store config data under %A_AppData%\%A_ScriptName%\%A_ScriptName%.ini
When the script starts i use IniRead which also provides a default value if the key isn't found - which is the case the script is executing for the first time.
The complementing IniWrite's in a OnExit subroutine/function will create the ini file if necessary.
This way no installation is needed and the config is stored in the proper, familiar place.
The autohotkey forum has dealt with this question before.
In that case, the user didn't want extra files -- period.
The method was to use the file system to save alternate data.
Unfortunately I can't find the post.
A simpler method is to use fileinstall command.
When the script is compiled, the external file is stored within the exe.
When the script executes the same command as an exe, the file is copied to the same
directory as the running script. It is a simple yet effective 'install'.
With a little testing for the config file, the fileinstall command can be skipped.
Skipping the fileinstall could allow changes to be made to the configuration after 'installation'
I have not tried saving settings within the compiled exe file, but I have included resources. I'm not sure which version of AHK you're using or how you are compiling, but I can right-click my scripts to compile. There's an option to compile with options, where you can include resources in your compiled exe.Compile with options
Is there a good technical or other reason why the MS hard-coded the Documents folder as the default location for WindowsPowerShell? MS has been criticized for too much configuration over convention in the past (WCF?), but a case can be made for more configuration in PowerShell. I, and I presume most developers, like to keep their development work centralized in a separate folder or volume away from personal and system files.
For instance, if you install PoshGit, it will install itself in C:\Users\Your Name\WindowsPowerShell\Modules. I don't want it to install itself there but in my own development partition d:\Dev\PowerShellScripts. There's no environment variable that controls this location.
Is there a reason for this or I just don't get it?
Can you explain yourself a bit more.
According to my understanding PowerShell.exe interpreter base directory is the one defined by $env:HOMEDRIVE, $env:HOMEPATH, that can be change using the user profile.
As shown in the screen shots here under :
Edited :
Ok, the screenshot comes from the user property in Active Directory MMC, you've got a simplest one in your windows seven user properties. But this has nothing to do with your problem.
Your problem is around the module installation. The think that you have to know is that Modules can be installed quite everywhere (even on a shared directory with some tricks). By default the environnement variable $env:PSModulePath points to the paths where Get-Module -ListAvailable look for them. So you can add d:\Dev\PowerShellScripts\Modules in this path and then copy the subfolder of C:\Users\Your Name\WindowsPowerShell\Modules created by PoshGit inside your Modules directory and it should work. Modules as opposite to Snapins don't need to be registered.
Now the reason why PoshGit choose to put module in user profile, raser than let you choose the place is PoshGit installer problem.
For more explanations read about Modules and about_environment_variables.
This seems so trivial, yet I can't get it to work..
I have an msi.dll wrapper (named Interop.WindowsInstaller.dll) which I need to sign. The way to do it is by signing it upon import (this specific case is even documented in MSDN: http://msdn.microsoft.com/en-us/library/zec56a0w.aspx).
BUT - no matter how I do it (w/ or w/o a keyfile, w/ or w/o adding "/delaysign"), the generated assemly's size is always 36,864 bytes and when viewing the DLL's properties there is no "Digital Signatures" tab (needless to say - the DLL is NOT signed).
What am I missing here?? (... HELP!...)
[Note: Eventually I got a hint from Karel Zikmund on this thread, which helped me solve the mystery. I'll paste my reply here - for the greater good].
So, I used the following line to sign-upon-import the assembly:
tlbimp C:\WINDOWS\system32\msi.dll /out:Interop.WindowsInstaller.dll /keyfile:MyKey.snk
I then copied the file to the appropriate location and built the project, but each time the build failed on the following error: Assembly generation failed -- Referenced assembly 'Interop.WindowsInstaller' does not have a strong name.
I thought the problem was with the tlbimp line, but after reading Karel Zikmund's reply and verifying that the DLL is strong-named (using sn -vf Interop.WindowsInstaller) I found out the problem.
Adding a reference to the "Microsoft Windows Installer Object Library" COM object actually planted a code block into the .csproj file.
I didn't realize it, but this block caused the DLL file to be regenerated from scratch upon each time the project was built. The generated file, of course, was not strong-named anymore.
The way I resolved it was to remove the reference to "Microsoft Windows Installer Object Library" from the project, and add a direct file reference to the imported (and already signed) Interop.WindowsInstaller.dll file.