Hello,
Is there VBScript code for Restart Manager (see link here) code to make Microsoft Word close and re-open?
I used Microsoft Word as an example. I just wanted to send the message to RestartManager to close specific application.
I've to read all the RestarManager documentation and get into this to catch what you are trying to do.
And you are right. This is a elegant solution to a lot of problems.
BUT, you have two problems.
First, from the Guidelines for applications in Restart Manager, the behaviour observed in word has to be coded in application. Applications need to be aware of the Restart Manager and know how to act. But well, maybe your applications handle it, but ...
Second is Microsoft does not provide a COM interface to the API. From the documentation: The Restart Manager DLL exports a public C interface that can be loaded by standard or custom installer.
So, a wrapper needs to be written.
Anyway, for a "scripting" workaround, InnoSetup pascal scripting lets you make use of the Restart Manager API.
Related
I am developing a small tool that can detecting which folders are being opened in windows explorer and bring it to front if a specific address has been opened.
I can use both C# and C++ and finally pick C# as it is easier than C++ to accomplish the same target. Then I googled the internet and knowing COM object SHDocVw.ShellWindows can help collect all windows being opened. Then I start looking for Microsoft document to see if any functions can help to achieve my other requirements. However, when I search shell related documents: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/ff521731(v=vs.85) I am warned that "We're no longer updating this content regularly. Check the Microsoft Product Lifecycle for information about how this product, service, technology, or API is supported." Moreover, some documents even say these techs will be deprecated in Win11 (See the following screenshot)
I am wondering what the status of these Shell related technical. If these are being deprecated. What's the alternative solution? I don't want my tool stop working when start using new Windows. Meanwhile, I am confusing in the study routine of learning Windows desktop technical. Looks like so many technical to achieve the same targets. Is there anyone can give me some road maps?
Last thing, it's really frustrating to search COM object documents at Microsoft sites. Is this tech going down?
Microsoft has been trying to kill win32/desktop applications since Windows 8. That parts of the documentation is labeled as "legacy" is not something I would worry too much about. Some of the shell functions have been marked as deprecated for 20 years but still work fine today and too many applications rely on them for Microsoft to successfully remove them.
The Internet Explorer warning is different and IE might actually go away but that does not affect IShellWindows which is also used by Explorer.exe and 3rd-party applications. Its implementation lives in a shell DLL and not in IE.
I'm looking for some information how to replace the default email program within Windows. So far I've been able to find limited information about changing the registry keys to point to a custom coded DLL. Microsoft mentions that there is a MAPI stub which is saved as Windows\System32\MAPI32.dll and there are functions that need to be implemented but not much detail on how it must be done.
I'll be writing the main program in C# but get the feeling I'll need to write the custom MAPI DLL in unmanaged C/C++
Any links or insight would be helpful.
Thanks.
Two things I can think of
modifying default email program is not related to DLL. See KB 299853. The sample is in VB but you can easily change it to C#.
associate the mailto: protocol to your program, which is already discussed here
Thanks Peon for the info.
Part of my research brought me information about Mozilla's Thunderbird.
Thunderbird may not fully implement Simple MAPI as many people have mentioned. However it gives a great outline of the DLL stub that needs to be overridden.
Anyone looking into creating a default email client, or at least acts like a default email client should look at the Thunderbird source code ( available off Mozilla's website ).
Also, install Thunderbird. It creates all of the proper registry changes that you'll also need to make.
https://stackoverflow.com/questions/38074930/windows-application-crash-issue-with-dllmain-c
use registry to change default email client. And code from the link will help you to run your code.
Code is in c++.
I am aware of both this and this questions.
Which unfortunately didn't quite answer what I'd like to know:
The answers in the above questions suggest that it has to do with adding shortcuts to the start menu, but that can't be the sole reason. So far I've been unable to reliably figure out what makes windows think my application is an installer in the first place and why does windows think it failed?
I do not want to simply suppress the message with a compatibilty tag in the manifests. I want to write a proper solution and tell Windows if my installation has failed or not. Also, what does the install using recommended settings option do, that comes along with the dialog? How can I properly utilize this functionality? Again, I don't want to simply disregard the features Windows provides, I'd like to use them.
I've been browsing around MSDN but with no success. I've asked google, but all I could find is ways to suppress the message using compatibility tricks in either the manifest or the registry. I'd be already grateful if someone could provide a viable resource on MSDN that covers this topic well.
So far, I am using a custom installer that utilizes several Windows API calls. I am not messing around with the Windows Registry other than registering two services. It also has requireAdministrator as the requested execution level (not that anyone cares, but this is suprisingly clean and simple - it's merely a flag in the project settings). I am currently not using MFC or CLR.
See Installer Detection, it lists what is checked to decide whether an executable is an installer.
"This program might not have..." is a product of "Program Compatibility Assitant", and is documented in the Application Compatibility: Program Compatibility Assistant (PCA) topic. According to the document the reinstall option applies XPSP2 compatibility mode.
We're starting a new custom project right now from a client and one of the requirements is the process cannot be terminated unless the system is shutting down, restarting, or logging-off.
This application monitors the USB interface. We will be using WMI to query the device periodically.
The client want's to run the application on Windows XP Operating System and doesn't like installing .NET. So we targeted Visual Basic 6 as our language.
My main concern is this application cannot be terminated. Our Project Adviser talks about Anti-virus and yes, some of the anti virus cannot be terminated. I was thinking how to do the same in Visual Basic 6. I know there will be API involved on the project but where should I go? so API is ok with me.
I saw some articles that converts the EXE to a SERVICE, create Windows Service in Visual Basic 6, etc.
So please .. share your thoughts.
If you want to be evil, you can call the (officially) undocumented RtlSetProcessIsCritical NTDLL function. This will immediately BSOD the machine if your process is terminated.
You cannot create a process that cannot be terminated without some sort of kernel-mode hooking, which involves writing a driver. You might want to look into Rootkits: subverting the Windows kernel if you're interested in that. However, even with kernel-mode hooking there are still numerous ways to terminate processes. The alternative is to use user-mode hooking, easily bypassed but enough for very simple projects.
The solution you want to use will depend on how far you want to go with the termination protection. And even if you do succeed in preventing process termination, there may be ways of preventing your application from working properly - e.g. killing the WMI service.
I think you want to look at writing an NT Service.
More info here: http://www.montgomerysoftware.com/CreatinganNTServiceinVisualBasic6/tabid/161/language/en-US/Default.aspxlink text
It's really frustrating coding in VB6 right now specially I dumped my head in C# for 2 years though I coded in VB6 for 5 years..
Moving back is a pain as if I am starting a new programming language.
To be honest, you are trying to do something in VB6 that it really isn't that great at.
When you say 'cannot be terminated' - what do you mean by that? There are several levels there:
a) App shows a window but the user cannot close it with the X button, or it does not show one
b) App shows no windows or maybe sits in task tray
c) App shows no windows and cannot be shut down from the Applications tab of task manager
d) App cannot be shut down from the process list of task manager
(a) and (b) are probably easiest to do in straight VB. (c) is still possible, but getting uglier. (d) gets you into hack territory and would almost certainly be frownd upon if you did manage it.
If you really need to stop users closing then you can probably hack it to a greater or lesser degree, but the real answer is as the others have said - a system service (this is exactly the srt of thing they were intended for). However that is one thing that VB6 isn't good at so the best solution to your problem is c#.
I would like to automate a windows app that comes only with as a GUI app (no support for command-line). The automation itself is relatively straightforward with AutoIt.
Yet, I am wondering, is-it possible to launch the Windows App from with a windows service (that would simply call the AutoIt script)?
Even if Auto-it can work with UAC, you will most likely run into Session Isolation troubles - i.e services and desktop don't mix and send messages to each other, unless explicitely coded to pass through it.
So it's possible, but it's not a piece of cake either.
You probably want to look at : Launching a .Net winforms application interactively from a service
While not at all advised because of complications associated with Session 0 isolation in the latest versions of Windows, AutoIt scripts can certainly be invoked from a Windows Service. Please see this page for a few sample scripts that work as expected when called from a Windows Service.
Unfortunately though, not all of the AutoIt functions seem to work in Session 0. We ran into trouble with the "Win*" routines (WinActivate, WinExists) so you should probably avoid those if you can. And since the documentation does not highlight the problematic functions be sure test thoroughly!