Some of our clients have a problem we can not reproduce here inhouse: Out software uses MS-Word for producing form letter. Since some of our clients use Office 2013, this function won't work anymore.
We tried to reproduce this and detect that on the affected systems Word won't start from command line. Starting via the link in the startmenu works. It also works to start Excel from command line.
Does anyone have an idea what the problem is and how to solve it?
You can try using start.exe from the command line:
c:> start winword
I'm wasn't familiar with it but tried it and it worked for me on Windows 7, with Office 2007. Found this site (windows-commandline.com). They claim it works for all versions of Word.
Just an FYI similar to Word
for Excel on command line and parameters
c:\> start excel "file path and location"
c:\> start excel "c:\somepath\myfile.xlsx"
worked for us to open a file created in VB 6.0 for Excel 2013
c:\excel does not work on command line for us either
I think WinWord will work with a file parameter too.
c:\> start winword "c:\somepath\myfile.doc"
We found the solution:
Our software still uses old 8.3 filenames - also long filenames are replaced with short ones. And it seems that Office 2013 don't like them anymore.
This is the executable location and file in Office 2013, as listed in the shortcut. You cannot start it by using winword either, in Win 8 32 bit.
"C:\Program Files\Microsoft Office 15\root\office15\winword.exe"
Try using the run prompt by pressing the windowsbutton+R. The run prompt will open and then Type winword to open MS Word and excel to open MS Excel.
Related
I am trying to install a program silently (the program is old, has InstallShield v7.00). However, every time I run the command, it does nothing and the setup.log file states "ResultCode=-8".
That ResultCode indicates that an invalid path to the InstallShield Silent installation script file was specified (which I am assuming to be the response file I generated earlier, which is named setup.iss).
Setup.exe and setup.iss are both in the same folder. I tried specifying the exact path to both files, and not, as seen in the list of commands I have tried below:
"C:\Test\setup.exe" /s /f1"C:\Test\setup.iss"
setup.exe /s /f1 setup.iss (CMD directory is in C:\Test)
setup.exe /s (Thought it would just find the setup file automatically as they are in the same folder)
I am trying to install EPSON OPOS ADK, for which the installation manual states the exact commands I am using are correct.
There is no MSI file contained in the EXE file (or, if there is, I cannot extract it with WinRAR and I could not find it in ProgramData while the setup was running).
Does anyone know what I am doing wrong or what I can do?
EDIT: Below is the contents of my setup.iss file:
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-DlgOrder]
Dlg1={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdWelcome-0
Count=7
Dlg2={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdLicense2-0
Dlg3={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdSetupType-0
Dlg4={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdStartCopy-0
Dlg5={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-AskOptions-0
Dlg6={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdFinish-0
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdWelcome-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdLicense2-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdSetupType-0]
szDir=C:\Program Files (x86)\OPOS\Epson2
Result=301
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdStartCopy-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-AskOptions-0]
Result=1
Sel-0=1
Sel-1=0
Sel-2=1
Sel-3=0
[Application]
Name=EPSON OPOS ADK
Version=031.000.01000
Company=SEIKO EPSON CORPORATION
Lang=0009
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdFinish-0]
Result=1
bOpt1=0
bOpt2=0
EDIT 2:
So I ran the recording for the .iss file again, but this time instead of just doing "setup -r", I did "setup -r f1"C:\"" instead. This should make no difference other than telling it where to save the recording. However, I got a different .iss file out of it. Here it is:
[InstallShield Silent]
Version=v7.00
File=Response File
[File Transfer]
OverwrittenReadOnly=NoToAll
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-DlgOrder]
Dlg0={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-Uninstall-0
Count=7
Dlg1={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdWelcome-0
Dlg2={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdLicense2-0
Dlg3={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdSetupType-0
Dlg4={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdStartCopy-0
Dlg5={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-AskOptions-0
Dlg6={0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdFinish-0
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-Uninstall-0]
Uninstall=0
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdWelcome-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdLicense2-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdSetupType-0]
szDir=C:\Program Files (x86)\OPOS\Epson2
Result=301
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdStartCopy-0]
Result=1
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-AskOptions-0]
Result=1
Sel-0=1
Sel-1=0
Sel-2=1
Sel-3=0
[Application]
Name=EPSON OPOS ADK
Version=031.000.01000
Company=SEIKO EPSON CORPORATION
Lang=0009
[{0EEDEE2B-7C9D-4584-B2B5-C28C93678BC1}-SdFinish-0]
Result=1
bOpt1=0
bOpt2=0
I was very happy when I saw it was different, and figured my issue would be solved. Well, not exactly.
Now, instead of getting ResultCode = -8, I am getting ResultCode = 0. A code of 0 indicates there was a successful installation. However, the program did NOT install. Nothing was touched. I noticed this before even looking at the code because it finished "installing" almost immediately after running the command, with no loading icons or anything.
So now, InstallShield is reporting that the program was successfully installed but it, in actuality, was not. I tried re-recording the .iss file numerous more times but I am just getting this same file now. The file is likely no longer the issue. However, I am at a loss for what the issue could be now.
Setup.iss: I guess the real problem might be that there is an error in your setup.iss file. Can we see its content? Maybe the setup.iss you are using is for another Setup.exe entirely? Try re-generating a new one?
UPDATE: Maybe have a look here as well: Epson OPOS ADK for .NET drivers for Windows 7
That silent.iss response file seems to lack a header section when compared with this documentation: Performing Silent Installations and Uninstallations (PDF, section "InstallScript Installations" page 3 onwards).
Setup.exe Extract: Maybe also make sure that this is not an MSI setup after all:
Short version: Programmatically extract contents of InstallShield setup.exe
Long version: Extract MSI from EXE
And:
Extracting from an MSI (administrative installation).
How to deploy the Installshield MSI without having to run Setup.exe
Sample Setup.exe Command Lines: For inspiration an ancient Itninja / AppDeploy PDF with sample Installshield setup.exe commands (I think the last few entries in the document were never finished, they just all say Setup.exe /uninst - so just ignore them). Did you try the /SMS parameter? I don't see how that would solve your particular problem, but you should know about the switch anyway.
Some Links:
InstallShield Error Codes (Setup.log)
InstallShield Setup Silent Installation Switches
Performing Silent Installations and Uninstallations (PDF)
EPSON OPOS ADK for .NET Manual (PDF)
Installshield 2018 Help File:
Setup.exe and Update.exe Command-Line Parameters
Advanced UI and Suite/Advanced UI Setup.exe Command-Line Parameters
Setup.exe (InstallScript Projects)
I have strange problem with new servers where is installed Windows Server 2016 Datacenter Core (Insider Preview 16257), Powershell 5.1. I can see all the commands used with up and down arrows, but I get nothing with Get-History cmdlet. Even when I enter some new cmdlets, Get-history did nothing at all. I need to save the history. I'm logged in with the same credentials. Thanks
Starting with Windows 10 / Server 2016, the PSReadline Module is included by default. This includes it's own per user history file. This file can be found with this command: (Get-PSReadlineOption).HistorySavePath.
This file is separate that than the per session history that is accessible with the Get-History command.
I've installed ActiveState Perl on my new Windows 10 PC. I've installed the same exact version of Perl on several of my own PC's, and it's installed on 100's of other users' PC's in my company. Same exact install, created by me.
This is the first time trying this on Windows 10. The basic actions of double-clicking a Perl script (*.pl) in Explorer cause a console window to open and Perl to run the script.
Also, in Windows Command Prompt, I can type perl.exe script.pl, and the script runs fine. But, when I just type script.pl, nothing happens. No output, no errors, no perl.exe processes visible in Task Manager.
The first time I ran a Perl script (from Windows Command Prompt, I believe, using just the script.pl syntax), Windows popped up a window asking me what program I wanted to use to open this file. Perl was the default, and I clicked OK.
I've never seen that window in Windows 7 or 8, so I'm thinking it's something specific to Windows 10, and that it's the thing that's somehow preventing me from just typing script.pl. Because, when launching script.pl, I'm requiring the file associations to pick the right program, but when I type perl.exe script.pl, perl.exe is being launched directly. But, that Windows 10 "pick your default program" thing is getting in the way when running from the command prompt by messing up the file associations.
Not 100% sure why it works from Explorer, though, but I'm pretty sure that I need to clear that default program thing. I removed the registry entry for .pl files under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts, but that didn't help.
This seems to be a more generic problem with Windows 10, or possibly just my installation of it, or a Group Policy I'm not aware of.
The following commands (run in a Admin command prompt) work fine in Windows 8.1 but not Windows 10:
assoc .foo=Foobar
ftype Foobar=C:\WINDOWS\system32\foo.bat %1
echo #echo off > foo.bat
echo echo The filename is %1 >> foo.bat
echo hi > foo.foo
foo.foo
The result should be the output:
The filename is C:\WINDOWS\system32\foo.foo
But Windows 10 does nothing. It seems to only allow built-in apps to be associated in this manner, and not BAT scripts of downloaded/installed EXEs.
Turns out that Microsoft reversed the polarity of a Registry setting in Windows 10, and this is biting other Perl programmers too. The solutions is to set HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\InheritConsoleHandles to "0".
MSDN post here: https://social.msdn.microsoft.com/Forums/en-US/f19d740d-21c8-4dc2-a9ab-d5c0527e932b/nasty-file-association-regression-bug-in-windows-10-console
Make sure your PATHEXT environment variable has .pl in it.
wmic process get /format:csv
What is wrong with this command in Windows 7?
I get:
Invalid XSL format (or) file name.
It's a bug in the wmic command. It's been suggested to copy XSL files into the %WINDIR%\system32 (or equivalent if 64 bit.) However, the command below works just as well without the need to copy files:
wmic process get ProcessId,Description,CommandLine,ExecutablePath,ParentProcessId /format:"%WINDIR%\System32\wbem\en-us\csv"
Of course, the "en-us" will be different for different locales.
If you want to redirect output to a file add a switch /output:"your filename here" before the process keyword
This is a bug in Windows 7 and Windows Server 2008 (also R2) WMIC. When you use (for example) Dutch regional settings in an English Windows installation, WMIC searches for the xsl files inside C:\Windows\System32\wbem\nl-NL, instead of C:\Windows\System32\wbem\en-US where they are.
Workarounds:
Copy or move the C:\Windows\system32\wbem\en-US\*.xsl files up into the C:\Windows\system32\wbem\ folder.
Change your regional settings to match your Windows language version, log out and back in.
Specify the full path: WMIC process get /format:"%WINDIR%\System32\wbem\en-US\csv".
This is a Windows 7 wmic bug. Change the International setings to English (United States), reboot and test.
I'm trying to install a custom build software on Windows Server 2008R2, 2008 and 2003. The software needs the "Desktop-Experience" feature from Windows to be installed.
I know I can check with servermanagercmd.exe (even though it's kind of cumbersome) in 2003 and 2008 - unfortunately, this does no longer work in 2008R2 (64bit) from inside an NSIS installer - it does work if I just run the command. Called from the installer, I'm getting a "servermanagercmd.exe is not recognized as an internal or external command, operable program or batch file."-error, even if I'm setting the working directory to c:\windows\system32 (yes, on a 64 bit machine, but there's no servermanagercmd.exe in sysWOW64).
Here's the line of code inside NSIS:
nsExec::ExecToStack 'servermanagercmd.exe -query | findstr "Desktop-Experience"'
In 2008R2, I thought the situation would actually improve, as PowerShell is now installed by default. However, when trying to get the information, I need to first load the ServerManager module inside PowerShell - but this module is not available for reading for Trusted Installer . So I'm facing the same situation again: If I'm running my powershell command from a command line, it works, but not from inside the NSIS installer.
Again, here's the line of code inside NSIS:
nsExec::ExecToStack 'powershell.exe "& "Import-Module ServerManager"'
The three(!) (double)quotation marks are actually correct.
So, does anybody know of a way to check whether Desktop-Experience is installed (and install it if not) in Windows Server 2008R2 from inside an NSIS installer? The solution does not need to work on Server2003 or 2008, because the string parsing from servermanagercmd.exe works there.
Are you using the macros in x64.nsh to turn off WOW64 redirection? (Or use "$windir\sysnative\servermanagercmd.exe")