When I used the latest version of McAfee Antivirus, I noticed that the shred feature can delete running files and then asks you to restart your computer. Do anyone know how does it delete running files without closing them?
It may depend on the OS and file system types. On Linux and Unix like, deleting a file a just removing an entry from a folder. The file is actually deleted on last close if no folder entry points to it. So you can safely delete a file even if it is opened in another process.
On Windows the MSDN says:
The DeleteFile function fails if an application attempts to delete a file that has other handles open for normal I/O or as a memory-mapped file
Usual tricks include:
try to close all processes having handles on that file. For an executable it generally means terminating all its instances
mark the file for deletion on next reboot. As you say that McAfee asks to reboot the computer it likely uses that option. The MoveFileEx WINAPI function has provision for that. Extracts from MSDN page (emphasize mine)
BOOL WINAPI MoveFileEx(
_In_ LPCTSTR lpExistingFileName,
_In_opt_ LPCTSTR lpNewFileName,
_In_ DWORD dwFlags
);
... lpNewFileName [in, optional]
The new name of the file or directory on the local computer....
If dwFlags specifies MOVEFILE_DELAY_UNTIL_REBOOT and lpNewFileName is NULL, MoveFileEx registers the lpExistingFileName file to be deleted when the system restarts.
Related
My C++ program is in a directory (A). After running ShellExecute() through this program, I open an application XShell, close my C++ program, and then I find that in the resource monitor, the A directory is occupied by the program XShell I enabled. How to solve it?
ShellExecuteW(NULL, L"open", L"D:\\Program Files\\NetSarang\\Xshell 6\\Xshell.exe", NULL, NULL, SW_SHOWDEFAULT)
After the C++ program exits, XShell occupies my C++ program directory.
I hope that after opening an application through ShellExecute(), this application does not occupy the directory of the C++ program.
The directory is occupied because the secondary program is inheriting that directory as its working directory. To avoid that, you can specify the desired working directory that the secondary program should use in the lpDirectory parameter of ShellExecuteW():
https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew
[in, optional] lpDirectory
Type: LPCTSTR
A pointer to a null-terminated string that specifies the default (working) directory for the action. If this value is NULL, the current working directory is used. If a relative path is provided at lpFile, do not use a relative path for lpDirectory.
For example, you can specify "C:\\" (which should always exist and be accessible).
I want to load DLL from sub folder of my application folder. So I put my.dll with all dependant dlls to /myfolder
I takes me a while to figure out the correct way to load it:
m_handle = LoadLibraryEx(".\\myfolder\\my.dll", 0, LOAD_WITH_ALTERED_SEARCH_PATH);
It works very well on Windows 7 & and later. However it returns error 998 ERROR_NOACCESS “Invalid access to memory location.” On Windows XP.
However loading this dll from the application folder works very well on all versions of Windows
PS: I tried to use SetDllDirectory with absoulte and relative paths to myfolder, but still no success on Windows XP
MSDN has this to say about the LOAD_WITH_ALTERED_SEARCH_PATH flag:
If this value is used and lpFileName specifies a relative path, the
behavior is undefined.
If you don't need to use the alternative search strategy, you can just pass 0 as the flags parameter. If you really need this flag then you must call GetFullPathName first to get the absolute path.
as we all know when we start a CMD.exe it will appear a console window and start with lines like:
Microsoft Windows [版本 6.1.7601]
版权所有 (c) 2009 Microsoft Corporation。保留所有权利。
C:\Users\hey>
but when i crate a windows console project in VS and my code like this:
int _tmain(int argc, _TCHAR* argv[])
{
auto h = LoadLibrary(__TEXT("cmd.exe"));
Sleep(99999);
}
just turns out a black window.no lines out!
as i expect，i can load this PE(windows executable format) file in my process so i do not have to start a new cmd.exe and redirect its stdIO to the process which start cmd.exe.(i know Loadlibrary with an exe file could start a exe in calling process without creating a new process)
and why is Loadlibrary not working?(it did not appear any words in the console window)
(i know Loadlibrary with an exe file could start a exe in calling process without creating a new process)
No, it can't.
You can pass the name of an EXE file to LoadLibraryEx if you use the LOAD_LIBRARY_AS_DATAFILE flag, in order to access its resources, but LoadLibrary neither runs the code in an EXE nor prepares the code for being run.
The entry point for an EXE is designed for having its own process. (I'm talking about the real entry point, which is usually provided by a language support library. It may have a name such as wmainCRT and its address, not the address of user-provided main(), appears in the PE header). Typically it exits by calling ExitProcess(), which will have catastrophic effects on your host EXE even if you do manage to map it into your memory space and call it.
The requirements for the entry point of a dynamically loadable library and an executable file are very, very different.
You can't run an executable via LoadLibrary. Use CreateProcess (or one of its siblings) instead.
From the LoadLibrary function docs (highlight in bold is mine):
LoadLibrary can also be used to load other executable modules. For example, the function can specify an .exe file to get a handle that can be used in FindResource or LoadResource. However, do not use LoadLibrary to run an .exe file. Instead, use the CreateProcess function.
I try to create a context menu extension for windows files/folders. I´ve already tried very much, but nothing worked for me. I already have such an extension for 32-Bit systems, but it´s outdated. I want to recreate it using C++ for 64-Bit systems.
This one was closest to what I want to do: Klick
But this is for 32-Bit systems. After reading the comments, I was able to modify&build it for x64.
Registering it using the system32/regsvr32.exe on my 64-Bit system, tells that it was successfully registered. All the registry entries are created correctly. But the menu item does not appear. I have no clue why...
Can someone help me? I can upload the project for you if you want.
UPDATE
I use the original Project from the link above and changed the following things:
1) set target to "x64"
2) since I couln't compile it, i changed the following things:
2.1) Before the includes in stdafx.h I added:
#define _ATL_NO_UUIDOF
2.2) I changed UINT to UINT_PTR here:
HRESULT CFSBankShellExtension::GetCommandString (
UINT_PTR idCmd,
UINT uFlags,
UINT* pwReserved,
LPSTR pszName,
UINT cchMax )
3) I changed txtfile to * in the .rgs file, so that it should apper on all filetypes.
4) I was able to compile and register it
If you can´t help me, it would be cool if you could upload a template, that will work on x64 system.
This article might help you as it worked out for my project..
Simple shell context menu
Context menus for all files, folders, and drives
You can also hookup context menus to all files, folders, and drives by
adding entries to the file type's *, Directory, and Drive registry
keys. For example, XP PowerToys adds the Open Command Window Here menu
to all folders with the following registry script:
REGEDIT4
[HKEY_CLASSES_ROOT\Directory\shell\cmd] #="Open Command Window Here"
[HKEY_CLASSES_ROOT\Directory\shell\cmd\command] #="cmd.exe /k \"cd
%L\""
I have a .exe created with a windows subsystem. I copy that .exe to another .exe, and I run:
editbin.exe /SUBSYSTEM:CONSOLE my.exe
So my intention is to have a .exe that runs with a GUI, and another .exe that is meant for command line operations (no GUI).
How do I check what subsystem is currently active in my C++ code?
Subsystem type (GUI, console, etc.) is stored in the PE header, which you can access via the ImageHlp functions. You can get it with the following code:
// Retrieve the header for the exe. GetModuleHandle(NULL) returns base address
// of exe.
PIMAGE_NT_HEADERS header = ImageNtHeader((PVOID)GetModuleHandle(NULL));
if (header->OptionalHeader.Subsystem == IMAGE_SUBSYSTEM_WINDOWS_CUI)
{
// Console application.
}
Relevent MSDN entries:
ImageNtHeader
IMAGE_NT_HEADERS
IMAGE_OPTIONAL_HEADER
Look at the ImageLoad function in the Imagehlp library. This returns a LOADED_IMAGE structure which has a IMAGE_NT_HEADERS structure in its FileHeader field. The OptionalHeader field in this structure is an IMAGE_OPTIONAL_HEADER which has a Subsytem filed containg the information that you want.
Far easier than spelunking in your own headers: check if you've got console handles.
For a GUI subsystem app, GetStdHandle() will return NULL handles.