I have a lot of different servers that I connect to. Each time I connect to a new machine I go through the several mouse clicks to setup basic options for cmd.exe, such as QuickEdit mode and expanding the screen display and buffers. This article describes what I do pretty well (with my own settings, of course): http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/commandpromptoptions.mspx?mfr=true
This is annoying. I would like to run a quick configureCmd.cmd script upon login that will update all of these settings automatically such that when I open the cmd.exe it is already configured without any additional work on my part. Running the script on login is easy, but I do not know where these settings are stored. I figured the Registry, but my experiments do not show any difference in HKLM | HKCU \Software\Microsoft\Command Processor.
Console Windows are not part of the command processor, so it follows that their settings are separate. Take a look at
HKEY_CURRENT_USER\Console.
Related
I added this command to httpd_uwamp.conf :
#LOG ROTATION
TransferLog "|C:/UwAmp/bin/apache/bin/rotatelogs.exe C:/UwAmp/bin/apache/logs/backup/access-%Y_%m_%d.log 5M"
It works fine, but cmd window is always visible while Apache is on.
Does anyone know how to hide this cmd window ?
This happens to me too with my access logs. I couldn't figure out a solid solution but for now I hide it through the command line using this tool found here:
https://steve.fi/Software/windowhide/
I've used it on Windows 7 and Windows Server 2012
Credits go to Steve Kemp .. steve#steve.org.ku
Revisiting... You might want to check on what user profile your server is starting and make sure it's running as a service.
My rotatelogs windows finally cleared away when I ran my server applications as a service..
Under the Task Manager the username is now SYSTEM and no longer my user name.
With this modification, an "Interactive Services Detection" window would popup presenting the option to view the prompts from a self-contained screen.
I also modified the httpd.conf and moved my "CustomLog" and "ErrorLog" lines to the directives as they were outside, though I don't think it'll affect the outcome.
I've been playing around with a Windows 7 virtual machine and found that by changing the shell registry value in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\shell I can use an arbitrary program (for example, paint) as the shell instead of explorer.
Now, given that I have no access to the tools afforded by explorer, how would I go about reverting this? This seems like a rather useful trick for demo machines and such, so I would hope that there's a way to revert them when done.
It turns out that keyboard commands (C-S-ESC, C-M-DEL) still work. Surprisingly, windows-r doesn't work. To revert it, open the task manager using C-S-ESC, then click new task, then you can either run explorer to start the gui shell, or regedit to change the default shell.
I'm currently working on laptops that go in Police Cars. They run an app called IMobile which is an extension of our CAD system, and allows them to do vehicle lookups, get more info on a call, etc.
The IMobile app is basically an IE overlay and it uses htm files that are on the local laptop. We've added in some simple VBScripts that do various tasks. Some common functions that are required for these tasks are in a VBscript called PoliceFunctions.vbs which is included in the same directory as all the other scripts. This method worked fine in previous versions of IE and Windows, however we're getting scripting errors in Windows 7 with IE8, specifically, 'ActiveX component can't create object: "Scripting.FileSystemObject"' and it references the functions script mentioned above.
If I set IE's settings to allow it to run ActiveX controls not marked as safe, the script runs fine, however I don't want do open a large security hole. I've tried adding localhost and the directory to the Trusted Sites list with no effect. I've tried re-registering SCRRUN.dll as mentioned in another post as well as wscript -regserver. And I've changed IE's settings to allow local Active Content with no success.
Anyone have any other ideas of how I can allow this script to run without opening a large security hole or having it nag the end user that his IE settings are going to bring about the apocolypse?
The explanation is long but explains how IE uses security zones to make trust decisions.
The URLAction of interest in this case is:
1201 Initialize and script ActiveX controls not marked as safe(URLACTION_ACTIVEX_OVERRIDE_OBJECT_SAFETY)
The default setting for this URLAction in the Local Machine zone is Prompt, and in all other zones it is Disable. Only if you change that setting to Enable will you bypass the prompt. You cannot use the Internet Control Panel to adjust the security settings for the Local Machine zone because only the other four zones are shown in this UI. To change the setting for the Local Machine zone, you can edit the registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0
Change the value for entry 1201 from 1 to 0
Write an ActiveX, implement IObejctSafety and wrap FSO methods in it. Note this is lying about the ActiveX's scripting safety but it is better than open to every unsafe ActiveX.
As the app "uses htm files that are on the local laptop" you could try to switch to a .hta application. For a quick test, just rename the *.html to .hta; if it 'works' add a suitable hta:application tag. To start
Just curious about the different ways vending machine companies / ticket companies get their application to run at startup full screen on a windows host machine.
Now first thing I am thinking is obvioulsy a link to the app in startup with a switch for -fullscreen.
There would be local / group policy as another option also.
Sidetracking a bit how do apps such as Skype work when they offer the "start skype when computer starts" option? registry?
Any thoughts / ideas / experience appreciated. Cheers
There are many ways to get an app to start automatically at Windows startup. The two most popular are
putting it into the Autostart folder
writing a special registry value (there is a kind of autostart section there)
I would guess most apps use one of these mechanisms.
As to "fullscreen mode", most kiosk-type systems / vending machines use a custom software as their GUI, so I guess that is developed to always run full-screen (there is no point in running it otherwise), so there no need to configure it for full-screen mode, it will always run like that.
With windows you do not have to have explorer.exe as your "shell".
The GPO settings "User Configuration > Administrative Templates > System > Custom user interface" can be set to be what ever you want - it could be a program, or a simple batch file.
So for example, you could have a batch file that - mapped a network drive, run a program, if that program terminates, the script then restarts the computer.
You would then use autologon for that computer to logon again and start the process all over again.
Most of the software add them to startup by creating a new REG_SZ value (with application path) at one (or more) of the following locations:
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce]
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices]
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce]
[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows]
NOTE: It may also be loaded from the [Load] or [Run] sections of your
WIN.INI file, found in the Windows directory, but you should not depend on it.
To start it in MAXIMIZED mode, you can design your application to resize itself to maximize mode on startup.
I have a program that was written on XP. What I've found out is that it doesn't work properly on Win7 because HLKM is no longer writable by non-admins.
Essentially, when you register the program, the licensing information is supposed to go into the registry. That information is valid for everyone on the computer, not just the one user, so I don't want to put it in HKCU. But any copy of the program needs to be able to edit that registry (even if it's a non-admin running it), because there are certain situations when it's going to go get updated license information from my web server (for example, if the registry data is lost or damaged, or if your current license is expired and it needs to see if we've applied an extension).
It's not horrible if it goes out to the web server for every unique user who starts up the program, but it causes some annoying issues, so I'd rather it continue to work the way it did in XP. Is there a way to store data in the registry and still have it shared under Win7, or am I going to have to start looking at storing an INI file on the drive?
Here is how I would architect it: your setup runs elevated and sets up the key. Then if their licensing gets corrupted or whatnot, you enable a button or menu item that has text like "fix license" or "update license". You put a shield on that button or menu item. When they click it, you launch a separate exe using ShellExecute. That exe has a manifest that requires elevation. It can then write to the protected area of the registry. The rest of the app can have a manifest with asInvoker.
If you want it to be completely invisible, either the whole app must always run elevated (annoying) or sometimes the app will just launch another exe that asks for elevation without warning - in which case the smart users will say no. A little less invisibility is a good thing imo.
Could you get the installer to make your particular area of the registry to be writeable by everyone? The installer will need to be run with elevated privileges anyway, I'd expect - so this would seem an ideal approach.