We have a printer driver that we need to build for all OS's from Windows XP to Windows 8, both x86 and x64 versions. I can do this manually using the WDK free build environments, but I need to automate the process - start a batch script and have all my builds ready.
Does anyone know how to do this?
Command-line windows for x86/x64 Debug/Release and various OS platforms differ only in enviroment variables. The scripts setting the environment variables are already available in DDK or Visual Studio. (To find out script names check properties of corrseponding command window shortcuts.) So the problem comes down to writing a Windows batch file setting environment variables and invoking build commands one by one. Most likely environment variables for each next platform overwrite ones from previous platform, but to be safe you can start each build in a separate clean cmd.exe process. Here is the main script:
start /W "cmd /C build_winxp_x86_debug.cmd"
start /W "cmd /C build_winxp_x64_debug.cmd"
...
start /W "cmd /C build_win8_x86.cmd"
start /W "cmd /C build_win8_x64.cmd"
Start /w waits for spawned cmd.exe process termination before executing the next line. Cmd /c terminates when corresponding build script completes.
Example of build script:
#rem Script setting environment variables from DDK
ddkpath\setenv.bat XP x86 dbg
#rem your build commands
cd your_driver_dir
build -cz
Related
In Windows PowerShell 5.1, after run & code ., a VSCode window opens, and the control returns back to PowerShell immediately. After the PowerShell exists, the VSCode will not be terminated.
On the other hand, when invoke other external program, such as WinMerge, after run & WinMergeU, a WinMerge window opens, and the control does not return back to PowerShell until WinMerge window is closed. And If PowerShell exists, WinMerge will be terminated.
Why the behaviour is different?
the difference is what is actuall happening:
when you run the command code, you are not really running code.exe. its starting a cmd script that spawns a new code.exe process with whatever arguments you passed it.
to see what a command actually executes, use the command get-command 'yourcommand', or with code get-command code.
this will show the follwing source: C:\Users\{username}\AppData\Local\Programs\Microsoft VS Code\bin\code.cmd.
Opening up this will show you:
#echo off
setlocal
set VSCODE_DEV=
set ELECTRON_RUN_AS_NODE=1
"%~dp0..\Code.exe" "%~dp0..\resources\app\out\cli.js" --ms-enable-electron-run-as-node %*
endlocal
so this means that in both cases you are waiting for execution to end, but for code its a code.cmd script and not actually code.exe.
If you want to start new processes and don't wait for them, you can use the command start-process winmergeu
I'm working to automate the install of some of our software and was able to do so using a batch file, but was having issues with getting the silent install working in PowerShell.
The batch file which is working properly to install the application is:
#echo off
start /wait Setup.exe -s -l=EN
echo %errorlevel%
I've tried the following code in PowerShell, but the GUI installer will appear when I attempt to run it.
cmd.exe /c "Start /wait c:\temp\application\setup.exe -s -l=EN"
I don't receive any error messages when running the PowerShell script, it just doesn't install the application silently.
Try this:
&{ "c:\temp\application\setup.exe" -s -l=EN }
This should call an external Commandline command from Powershell.
The braces are not always strictly necessary either if you are just running the command and not doing anything with the output the following would likely work
& c:\temp\application\setup.exe -s -l=EN
I'm trying to run a daemon in the scala console in the background. I can get it to run the program but it locks the console window when it is running, and therefore forces me to use a separate window to stop the daemon to unlock the original console. I'm running the scala console in a windows powershell through sbt.
I can use the command prompt to successfully run the program in the background using: start /b program, but running ("start /b program").! in the scala console fails.
This will run the program in scala console but will lock the window:
("cmd /c start program").!
How can I get the program to successfully run in the background so I still have access to the current console?
I've been fiddling with /E:ON using /b as an extension of start to no avail.
These are results from cmd /?
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\>cmd /?
Starts a new instance of the Windows XP command interpreter
CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF] [/F:ON | /F:OFF] [/V:ON | /V:OFF]
[[/S] [/C | /K] string]
/C Carries out the command specified by string and then terminates
/K Carries out the command specified by string but remains
/S Modifies the treatment of string after /C or /K (see below)
/Q Turns echo off
/D Disable execution of AutoRun commands from registry (see below)
/A Causes the output of internal commands to a pipe or file to be ANSI
/U Causes the output of internal commands to a pipe or file to be
Unicode
/T:fg Sets the foreground/background colors (see COLOR /? for more info)
/E:ON Enable command extensions (see below)
/E:OFF Disable command extensions (see below)
/F:ON Enable file and directory name completion characters (see below)
/F:OFF Disable file and directory name completion characters (see below)
/V:ON Enable delayed environment variable expansion using ! as the
delimiter. For example, /V:ON would allow !var! to expand the
variable var at execution time. The var syntax expands variables
at input time, which is quite a different thing when inside of a FOR
loop.
/V:OFF Disable delayed environment expansion.
You should use forking in SBT, that's exactly what it is for.
For your case set this setting in your SBT build:
fork in run := true
By default stdin will not be connected to your forked process, to enable it do:
connectInput in run := true
Figured it out thanks to #som-snytt's link to #michael.kebe's answer on this SO entry: How does the “scala.sys.process” from Scala 2.9 work?
val pb = Process("""program""").run
Does exactly what I wanted
I would like to have the console window kept open when running a scheduled task which executes a batch file. If I run it manually meaning execute the batch file the window stays open but through task scheduler it doesn't open but I can see the task is still running. I put a pause at the end to do this.
#echo off
TITLE PROCESS_MGR
tasklist /FI "IMAGENAME eq JOESMO.exe" | find /I "JOESMO.exe">nul &&(echo PROCESS
JOESMO.exe IS ALREADY RUNNING!
echo %DATE%
echo %TIME%
pause
) || (
echo JOESMO PROCESS IS NOT RUNNING
cmd /c start "JOESMO.exe" "C:\Users\xxxx\Documents\
Visual Studio 2010\Projects\Projects2013\JOESMO.exe"
pause)
I found this suggestion cmd /k myscript.bat but having creating the task in task scheduler for windows server 2008 I am not sure where to apply this. I added /k to the add arguments box in edit action in task.
In the Scheduled Task dialog, just before the name of the batch file it's going to run (it's labeled Program/script. You now have something like:
myscript.bat
Change it to
cmd
Add the following to the **Add Arguments (optional) entry:
/k "C:\My Batch File Folder\MyScript.bat"
Tested on my system (Win7 64-bit), and it worked perfectly. I'm looking at the open command window it created as I type this text. :-)
Unfortunately Ken's solution didn't work for me on a Windows 2008 R2 Std server, I was able to launch an interactive window by modifying the scheduled tasks setting using schtasks.exe
In a command window I did the following command:
schtasks /Change /TN "My Task" /IT
However that does require you be logged in as the same user context in which the scheduled task is executing. So if your scheduled task is use the localsystem "taskaccount" then you will have to log into the system as the "taskaccount" user.
Oddly enough it worked when I manually run the task but it didn't pop for me when it kicked off at a scheduled time.
Ken's answer didn't worked for me.
Found this way of doing :
in your BAT file (create one if you only have an EXE) :
start C:/Absolute/Path/To/MyScript.exe myScriptArg
works like a charm !
Note: In the scheduled task, you must check "Exec only if user is logged"
Create a shortcut to the Batchfile and put that in the action. Worked for me
I tried all of the above, but they did not work for me. Here is what I did to get this to work:
Platform
Windows Server 2003 R2 SP2
ActivePERL v5.10.1
Steps
Create DOS BATCH script -- this runs the actual program, ie, myscript.bat
Create PERL script to call the DOS batch script, ie, myscript.pl
myscript.pl is a 1-line script: system("e:\scripts\myscript.bat");
Create scheduled task: perl myscript.pl
The DOS command prompt window now always opens up. And more importantly, the task now successfully runs and completes. NOTE: The scheduled task RunAs user is logged in to the server.
I have a job in Hudson that builds on a Windows XP slave. I know that symlinks are not possible (directly) in Windows XP, and so I am trying to use junctions instead. I wrote a batch script:
#echo off
if "%1" == "" goto ERROR1
if "%2" == "" goto ERROR2
goto create
:create
echo Creating junction for %1 at %2
if exist %2 junction -q -d %2
md %2
junction -q %2 %1
goto :eof
:ERROR1
echo Source directory not specified
goto :eof
:ERROR2
echo Destination directory not specified
goto :eof
In my job, when I call this script, it hangs at the line echo Creating junction for %1 at %2. This is my Hudson "Execute Windows Batch Command":
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
copy C:\Data\Scripts\slink.bat .
call slink.bat C:\Data\3rdParty64 3rdParty
call slink.bat %WORKSPACE%\..\..\..\tds.core\label\%label% tds.core
...and this is the output:
C:\Data\Hudson\dev\workspace\Common_Windows\label\DFWW9202>call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
Setting environment for using Microsoft Visual Studio 2010 x64 tools.
1 file(s) copied.
Creating junction for C:\Data\3rdParty64 at 3rdParty
Any ideas? (if this is not the right site, please redirect..sorry and thanks!)
The best way to solve this is to: pass /accepteula command-line argument to the junction command.
eg:
junction -q %2 %1 /accepteula
This procedure did not work for me, but I did narrow down the real problem.
Some background: The very first time the "junction.exe" program is ever run by a user on a Windows machine, it throws up an End User License Agreement (EULA) with an Agree button. Once that user clicks on the "Agree" button, they can use the utility normally.
junction.exe was stalling for Hudson because the service was being run as "Default User", and "Default User" never clicked on the Agree button. This caused junction.exe to invisibly and indefinitely stall, waiting for that click, which of course will never arrive.
The way we fixed it was to configure the system to run the Hudson service as a well known account, instead of as Default User. Then we logged into the Windows machine as that account, ran junction.exe, clicked on the Agree button, then logged off.
junction.exe has worked nicely in Hudson ever since.
The other option is to move to Windows Server 2008. I'm told that version has the junction functionality in a new "mklink" utility that comes built into the OS itself, and does not have a EULA.
Never mind, found it if anyone else is looking - I changed the "call" to slink.bat to "start /B", and added full paths, so:
call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x64
start /B C:\Data\Scripts\slink.bat C:\Data\3rdParty64 3rdParty
start /B C:\Data\Scripts\slink.bat slink.bat %WORKSPACE%\..\..\..\tds.core\label\%label% tds.core