|
|
|||||||
Is there any way to get the Microsoft OS version as well?? (64Bit or 32Bit).. thanks in advanced. |
||||||||
|
|
|||||||
Originally Posted By: matzas Is there any way to get the Microsoft OS version as well?? (64Bit or 32Bit).. thanks in advanced. Yes there is. Have a look at the OSArchitecture()UDF. |
||||||||
|
|
|||||||
Quote: Is there any way to get the Microsoft OS version as well?? (64Bit or 32Bit).. thanks in advanced. Also see the @OnWoW64 macro. From the manual..."@ONWOW64 If this macro returns 1, KiXtart is running in the WOW64 environment on a Windows x64 system." |
||||||||
|
|
|||||||
Originally Posted By: matzas Is there any way to get the Microsoft OS version as well?? (64Bit or 32Bit).. thanks in advanced. Code: ;;RETURNS 40 element array ;; 0 short/full operating system description ;; 1 kernel description (Win2K, WinXP, Win2K3, Vista) ;; 2 operating system role (workstation, member server, domain controller) ;; 3 operating system service pack level ;; 4 operating system build level ;; 5 uni/multi-processor type ;; 6 Computer Name ;; 7 registered owner,organization ;; 8 Serial Number ;; 9 Install Date - YYYY/MM/DD hh:mm:ss ;; 10 Local Date/Time - YYYY/MM/DD hh:mm:ss ;; 11 Last Boot Time - YYYY/MM/DD hh:mm:ss ;; 12 TimeZone info (Std, Daylight, Bias) ;; 13 Primary Domain Affiliation ;; 14 Installed Hotfix list ;; 15 OS Version (numeric) ;; 16 Future Use ;; 17 O/S Architecture ;; 18 Install Method (Clean, Upgrade, SysPrep) ;; 19 RAM/PageFile Info (location MinSize MaxSize) ;; 20 System Brand ;; 21 System Model ;; 22 System S/N ;; 23 System BIOS Revision ;; 24 Processor Type ;; 25 Processor Speed ;; 26 Processor Count (Physical) ;; 27 Processor Count (Logical) ;; 28 Processor Cores ;; 29 Physical Memory ;; 30 Fixed-Disk Labels, null if none ;; 31 Fixed-Disk Mount Point ("d:\" for drives, path for mounted volumes) (2K3 & higher) ;; 32 Fixed-Disk Drives (A:-Z:, or "MV:" for mounted Volumes) ;; 33 Fixed-Disk Capacities, bytes ;; 34 Fixed-Disk FreeSpace, bytes ;; 35 CD-ROM Disk List ;; 36 Connected Network Drives ;; 37 Hardware Architecture ;; 38 Processor DataWidth ;; 39 Future Use Code: 00 Microsoft Windows 8 Pro 01 Unknown 02 Member Workstation 03 04 9200 05 Multiprocessor Free 06 ICWD011 07 user/ 08 00178-10077-75869-AA763 09 2013/01/05 23:33:30 10 2014/01/07 11:36:02 11 2013/12/21 14:46:27 12 Eastern Standard Time / Eastern Daylight Time / 5 13 itcg.lan,ITCG 14 15 6.2.9200 16 17 64-bit 18 Clean 19 12224 20 Hewlett-Packard 21 HP Compaq 8100 Elite CMT PC 22 2UA04305JS 23 HPQOEM - 20091216 24 Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz 25 2933 26 1 27 8 28 4 29 12817047552 30 ,Work,System Reserved 31 C:\,E:\,\\?\Volume{67bb6fab-57b9-11e2-be65-806e6f6e6963}\ 32 C:,E:,MV: 33 749786361856,750153334784,366997504 34 362244497408,308648706048,113971200 35 B:,D: 36 <SNIP>W:=\\icwwcmsp01\WebSites,X:=\\icwismsp01\MediaRoot,Y:=\\icwifpsp01\SWDist 37 x64 38 64 39 Also, if there are any suggestions for the "Future Use" fields, I'll see what I can do to update the UDF to include them. Glenn |
||||||||
|
|
|||||||
Originally Posted By: ShaneEP Quote: Is there any way to get the Microsoft OS version as well?? (64Bit or 32Bit).. thanks in advanced. Also see the @OnWoW64 macro. From the manual..."@ONWOW64 If this macro returns 1, KiXtart is running in the WOW64 environment on a Windows x64 system." my mistake --> I wanted to know the microsoft office version 64bit or 32 bit. is there anyway to figure that?? thanks, |
||||||||
|
|
|||||||
The only consistent method I could find online to determine the bitness of Office, is to use WMI. It is pretty slow, but seems to work. Code: $objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") $colSoft = $objWMIService.ExecQuery("SELECT * FROM Win32_Product WHERE Name Like 'Microsoft Office%'") If $colSoft.Count = 0 $bits = "na" ; Office not installed Else For Each $objItem In $colSoft $item = $objitem.caption If InStr($item, "-bit") AND Len($bits) = 0 $bits = Right(Split($item, "-bit")[0], 2) Endif Next EndIf ? "Bits: "+$bits get $ |
||||||||
|
|
|||||||
Originally Posted By: ShaneEP The only consistent method I could find online to determine the bitness of Office, is to use WMI. It is pretty slow, but seems to work. Code: $objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2") $colSoft = $objWMIService.ExecQuery("SELECT * FROM Win32_Product WHERE Name Like 'Microsoft Office%'") If $colSoft.Count = 0 $bits = "na" ; Office not installed Else For Each $objItem In $colSoft $item = $objitem.caption If InStr($item, "-bit") AND Len($bits) = 0 $bits = Right(Split($item, "-bit")[0], 2) Endif Next EndIf ? "Bits: "+$bits get $ thanks, but it seems it's not given the right bits. i have office Professional Plus 2010 32bit installed. my version is: 14.0.7106.5003 (32-bit). and when i run the script it says "Bits: 64".. is there another way to get this information?? (the bits..) thanks in advanced... |
||||||||
|
|
|||||||
Would you mind creating a new post, where we can trouble shoot this more? Don't want to further hijack this thread. |
||||||||
|
|
|||||||
Moved post and replies to a separate thread. |
||||||||
|
|
|||||||
If you can install an additional dll on your computers, the following UDF will get the bit version of an exe. See notes in the thread. PSGetBinaryType - http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=204276#Post204276 Thinking out loud... Do a registry check for the path of your office installation Since Word is included in all versions of office, use the path with WINWORD.EXE Use the function above to check for 32 or 64 bit. |
||||||||
|
|
|||||||
And if you do a registry search on the GUID of office... http://themagickube.blogspot.com/2011/08/detect-whether-installed-ms-office-2010.html http://social.msdn.microsoft.com/Forums/...t?forum=worddev |
||||||||
|
|
|||||||
Yeah I came across both of those solutions when I googled it as well Allen...But with both methods it seemed there were people that it did not work for. Of course those people may have been mistaken. |
||||||||
|
|
|||||||
Also, another side note...The WMI reports 32 bit on my win 8.1 laptop. Whereas the outlook bitness registry value says x64. Wonder if WMI is just reporting incorrectly? |
||||||||
|
|
|||||||
it's windows 8.x dude. office bitness is the least of your worries |
||||||||
|
|
|||||||
Originally Posted By: Lonkero it's windows 8.x dude. office bitness is the least of your worries LOL |
||||||||
|
|
|||||||
Hahaha, no doubt about that. |
||||||||
|
|
|||||||
Originally Posted By: Allen And if you do a registry search on the GUID of office... http://themagickube.blogspot.com/2011/08/detect-whether-installed-ms-office-2010.html http://social.msdn.microsoft.com/Forums/...t?forum=worddev thanks... Code: Break On If @onwow64 = 1 $SearchKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Office\14.0\Common\InstalledPackages" Else $SearchKey = "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" EndIf $RegArray = SearchReg($SearchKey,"Outlook",7) If @Error ? 'No matching items found' Else For Each $value in $RegArray ? $value $x = Join(Split($value, $SearchKey + "\"), "") If SubStr($x, 1, 1) = 9 ? "office found" If SubStr($x, 20, 1) = 1 ? "Office 64Bit found" $OfficeBit = 64 Else ? "Office 32Bit found" $OfficeBit = 32 EndIf EndIf Next EndIf ? Get $x Exit ;; ;;====================================================================== ;; ;;FUNCTION SearchReg() ;; ;;ACTION Searches a specific registry path for a value ;; ;;AUTHOR Allen Powell ;; Adapted, formatted, & documented by Glenn Barnas ;; ;;VERSION 1.0 / 2014/01/11 ;; ;;SYNTAX SearchReg(Key, String, Search) ;; ;;PARAMETERS Key - Required - ;; ;; String - Required - ;; ;; Search - Required - ;; ;; 1 For Value ;; 2 for ValueName ;; 3 for Value and ValueName ;; 4 for KeyName ;; 5 for Value and KeyName ;; 6 for ValueName and KeyName ;; 7 for search in all ;; ;;Remarks: ;; KiXtart reads and writes default ValueNames as an empty string. ;; SearchReg() replaces the empty ValueName with the text: <Default> ;; Remember to replace the text '<Default>' with an empty string if you want to check ;; the found entries further. ;; ;;RETURNS ;; ;; Array containing values where SearchFor string was found. ;; arraymember format is: ;; KeyName<=>ValueName ;; (If the Searchstring is found in the KeyName, ValueName is set to <KeyName> ;; ;; Errors returned: ;; @Error 1 = No data returned from search ;; ;; ;;DEPENDENCIES none ;; ;;TESTED WITH WXP, W2K3, W2K8, W2K12, Win7, Win8 ;; ;;KiXtart: ;; KiX 4.20 ;; ;;Example: ;; Break On ;; $RegArray = SearchReg("HKEY_LOCAL_MACHINE\Software\Microsoft","dir",7) ;; If @Error ;; ? 'No matching items found' ;; Else ;; For Each $value In $RegArray ;; ? $value ;; Next ;; EndIf ;; ? Get $x ;; ;; ;;Source: Function SearchReg($_Key, $_Str, $_SrcIn) Dim $_Idx Dim $_vName Dim $_Value Dim $_Num Dim $_SubKey Dim $_fArr Dim $_mbr $SearchReg = '' $_Num = 0 $_Idx = 0 $_vName = EnumValue($_Key, $_Idx) Do $_mbr = '' If $_SrcIn & 1 $_Value = ReadValue($_Key, $_vName) If InStr($_Value, $_Str) $_mbr = $_Key + "<=>" + IIf($_vName, $_vName, '<Default>') EndIf EndIf If ($_SrcIn & 2) And InStr($_vName, $_Str) $_mbr = $_Key + "<=>" + $_vName EndIf If $_mbr ReDim Preserve $SearchReg[$_Num] $SearchReg[$_Num] = $_mbr $_Num = $_Num + 1 EndIf $_Idx = $_Idx + 1 $_vName = EnumValue($_Key, $_Idx) Until @Error $_Idx = 0 $_SubKey = EnumKey($_Key, $_Idx) While $_SubKey If ($_SrcIn & 4) And InStr($_SubKey, $_Str) ReDim Preserve $SearchReg[$_Num] $SearchReg[$_Num] = $_Key + '\' + $_SubKey + "<=><KeyName>" $_Num = $_Num + 1 EndIf $_fArr = SearchReg($_Key + "\" + $_SubKey, $_Str, $_SrcIn) If @Error = 0 For Each $_mbr in $_fArr ReDim Preserve $SearchReg[$_Num] $SearchReg[$_Num] = $_mbr $_Num = $_Num + 1 Next EndIf $_Idx = $_Idx + 1 $_SubKey = EnumKey($_Key, $_Idx) Loop Exit VarType($SearchReg) = 8 EndFunction |
||||||||
|
|
|||||||
I believe all you need to do is check if the program installation path. x86 32-bit version C:\Program Files (x86)\Microsoft Office\Office15 x64 64-bit version C:\Program Files\Microsoft Office\Office15 |
||||||||
|
|
|||||||
LOL Sometimes the simple things are overlooked. |
||||||||
|
|
|||||||
There would have to be, at a minimum, a OS bit check too for Doc's suggestion to work. If you have a Windows 32 bit OS, using the logic above, would produce Office 64bit. |
||||||||
|
|
|||||||
I think the @onwow64 would be a good starting point for that. I am not really sure why would one want to do a searchreg() though. I have 32bit office 2010 and that searchreg() code above will say I have 64bit just because office 2010 does come with some 64bit components. for the registry route you would need to search for specifically: {9XXX0000-AAAA-XXXX-B000-0000000FF1CE} where X-denotes stuff you don't care about and B stands for bitness, 1 being 64bit office. the AAAA you need to filter against as you want only the office key, not the individual components, so search for one of the following values in the AAAA field: 0011 Microsoft Office Professional Plus 011D Microsoft Office Professional Plus Subscription 0012 Microsoft Office Standard 0013 Microsoft Office Home and Business 0014 Microsoft Office Professional 002F Microsoft Office Home and Student |
||||||||
|
|
|||||||
No, don't forget that x64 will redirect calls so that needs to be accounted for. Also I'm mentioning the path where to look for the EXE not just if the path exists as it will exist with a few files in it on x64 even if you have the 32-bit Office installed. But if you have the 64-bit version of Office installed then the EXE files will be in the C:\Program Files\Microsoft Office\Office15 folder. IF you find Excel, Word etc in the C:\Program Files\Microsoft Office\Office15 folder then you have to be running the 64-bit version of Office. |
||||||||
|
|
|||||||
So are you saying this... Code: if exist("C:\Program Files\Microsoft Office\Office15\WinWord.exe") ? "Office 64bit" else ? "Office 32bit" endif ...will produce the correct results whether it is Windows 7 32bit or Windows 7 64bit? |
||||||||
|
|
|||||||
Have not tested to confirm but in a nutshell yes something like that. |
||||||||
|
|
|||||||
No, because that code would return Office 64-bit on a 32-bit version of Windows. |
||||||||
|
|
|||||||
Code: If EXIST(%%ProgramFiles(x86)%%) ;Windows = 64-bit, check for Office If EXIST("%%ProgramFiles%%\Microsoft Office\Office15\WinWord.exe") ? "Office 64bit") EndIf If EXIST("%%ProgramFiles(x86)%%\Microsoft Office\Office15\WinWord.exe") ? "Office 32bit" EndIf Else ;Windows = 32-bit, if there is office, office will be 32-bit EndIf |
||||||||
|
|
|||||||
I've got to go with Arend on this one, since a 32-bit platform will only have a "Program Files" path.. MS might have done better to name the new folder "Program Files(x64)". Something like this will work but doesn't validate the presence of the 32-bit app: Code: If %PROCESSOR_ARCHITECTURE% = 'x86' 'Office 32bit' @CRLF ; Can't be 64-bit on x86 platform Else ; 64-bit platform - see which version of Office is present If Exist('C:\Program Files\Microsoft Office\Office15\WinWord.exe') ; app found in 64-bit location, is x64 'Office 64bit' @CRLF Else 'Office 32bit' @CRLF EndIf EndIf Code: Function OfficeBits() If %PROCESSOR_ARCHITECTURE% = 'x86' $OfficeBits = 32 ; Can't be 64-bit Else ; 64-bit platform - see which version of Office is present If Exist('C:\Program Files\Microsoft Office\Office15\WinWord.exe') ; found in 64-bit path $OfficeBits = 64 Else If Exist('C:\Program Files(x86)\Microsoft Office\Office15\WinWord.exe') $OfficeBits = 32 ; found in 32-bit path Else $OfficeBits = 0 ; not found! EndIf EndIf EndIf Exit 0 EndFunction The WMIInstalledProducts UDF (download from my web site) returns the product GUID. If the "Microsoft Office" product is found, there is a value in the GUID that returns the product bitness. Glenn |
||||||||
|
|
|||||||
I think that also has problems because it is only looking for Office15. I think one would have to instead search for winword.exe such as: Code: dir "c:\program files\microsoft office\winword.exe" /s /b |
||||||||
|
|
|||||||
Yup, which is why I'd use the WMIInstalledProducts (or similar WMI calls) to get a list of apps, then search for the Microsoft Office product, then check the "bitness" flag. Does all the work to detect the product, version, and bitness. Of course, this has been a discussion about general methods, with little work done to create an all-encompassing process. So - are you up to writing this and posting a UDF, Brad?? Glenn |
||||||||
|
|
|||||||
How about this version? There are still holes (office installed in irregular path, etc..), but should work for the majority. Code: Function OfficeBits() $version = Right(ReadValue("HKCR\Word.Application\CurVer", ""), 2) If Len($version) If @OnWow64 AND Exist("C:\Program Files\Microsoft Office\Office"+$version+"\winword.exe") $OfficeBits = 64 Else $OfficeBits = 32 Endif Else $OfficeBits = 0 Endif EndFunction |
||||||||
|
|
|||||||
Is WMI always guaranteed to be installed and active? Before writing something to utilize that, we should get that question answered. Given that, I'm more than happy to work on it. |
||||||||
|
|
|||||||
My issue with WMI, is that it takes a really long time. Probably about 45 seconds to a minute on this XP machine Im on. |
||||||||
|
|
|||||||
Maybe you need new hamsters? |
||||||||
|
|
|||||||
No - I have new (well fed) hamsters - i7 3GHz 8-core workstation w/ 12G and it takes 25-35 seconds to do a WMI Products query. That's why I suggested doing the collection via a Run of an independent job with the inventory script I posted in the vault. I can't imagine doing that query over the LAN! With my Kix HelpDesk utility, the tool takes an average of 45 seconds to query a remote workstation without any agents. Using KixForms & sockets, I can send a request, perform the query locally, and return the array in less than half of the time - often 12-15 seconds. I don't do a Products query, which seems to take forever on any system. Glenn |
||||||||
|
|
|||||||
I am actually leaning towards the registry query, even if it is little complex with all the sku options, it atleast works. looking for a path that might not even be there since user can change the path during installation is utterly unreliable. edit, and what comes to the wmi query, does that not tricker the software inventory refresh? you know, the one that spills 100 lines of event lines in the eventlog? |
||||||||
|
|
|||||||
I would vote for the registry lookup as well honestyl...I was just too lazy to look up all the possible GUID values. |
||||||||
|
|
|||||||
done it.will post in a sec. |
||||||||
|
|
|||||||
there ya go: http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=208395 |
||||||||
|
|
|||||||
Well done sir. I guess there weren't as many GUIDs as I thought. I was drastically over complicating it in my head. It works on Win XP with office 2010 32 bit installed. Will try on Win 8 with 64 bit later. But I don't see why it wouldn't work. |
||||||||
|
|
|||||||
win8 breaks everything. should have added to the remarks that it isn't supported. worked fine on win7 64bit with 32bit office. and, if you only have word or excel or project or whatever (remember the works installations back in the day with word added?) this should not work as the code is looking for only office sku's and skipping single component ones. |
||||||||
|
|
|||||||
hmm... I didn't even remember to check on the first part... guess it all works fine without it |
||||||||
|
|
|||||||
had to change the GUID instr check to right() as it accepted security updates in it's original form. |
||||||||
|
|
|||||||
Appeared to work for me under Win 8. |
||||||||
|
|
|||||||
I was thinking you would have to check on the first section as well. That's why it seemed so complicated. But I think skipping to the product ID portion works well. |
||||||||
|
|
|||||||
yea, I was thinking about that too but... see this: http://support.microsoft.com/kb/2186281 we don't need to know if it is released version of RC or even beta. it still is office. |
||||||||
|
|
|||||||
Both the OfficeBitness() and OfficeVersion() returned correct value on Win 8.1 with Office Pro 2013 64-bit. |
||||||||
|
|
|||||||
awesome. thanks Shane. |
||||||||
|
|
|||||||
Arg... boys and girls certainly by now you know how to run and check all that stuff as even BATCH can properly test for x64 and the correct folder. Since Lonkero has already written a UDF for this I won't bother with the code but perhaps those with a bit of time might want to revisit batch and adjust for KiX coding. |
||||||||
|
|
|||||||
why won't you bother and show this boy/girl how to accomplish this with a batch. |
||||||||
|
|
|||||||
Ha... +1 |
||||||||
|
|
|||||||
I missed Arend's post but yes essentially that - http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=208377#Post208377 Code: pushd "%~dp0" cd /d "%~dp0" cls @echo off if not defined ProgramFiles(x86) goto x86 echo Basic check says we're on x64 64-bit so add some code to do something ... goto eof :x86 echo Basic check says we're on x86 32-bit so add some code to do something ... goto eof :eof pause popd |
||||||||
|
|
|||||||
that does not work if office install location is anything but default. so I am still waiting on this simple batch script that can do that. |
||||||||
|
|
|||||||
I said a simple check for the folder not a more robust UDF that can check for Office version regardless of location. |
||||||||
|
|
|||||||
Originally Posted By: NTDOC Arg... boys and girls certainly by now you know how to run and check all that stuff as even BATCH can properly test for x64 and the correct folder. I do not see comment about simple. I see you saying that even batch file can properly test for the CORRECT folder. the whole point for the UDF was to get the CORRECT info, because no simpler way was presented. and who would use a batch script that does not give correct information unless all conditions are met? it is more reliable to just guess which one it is. |
||||||||
|
|
|||||||
never mind Lonk - lost in translation I suppose. |
||||||||
|
|
|||||||
Ok, here you go then: Code: @ECHO off FOR /f "tokens=3" %%a IN ('reg query^ "HKLM\Software\Microsoft\Office\14.0\Outlook" /v Bitness') DO ( SET answer=%%a ) IF %answer%==x86 ( GOTO :x86 ) ELSE ( GOTO :x64 ) :x86 MSG * Office 2010 is x86 GOTO :END :x64 MSG * Office 2010 is x64 GOTO :END :END pause You can add support for more office versions, this is just my proof of concept :P I KNOW the x64 bit is not fool proof but I can't be bothered, this is a PoC like I said. |
||||||||
|
|
|||||||
I tried that method at home Arend. Unfortunately it does not work if only office is installed without outlook. Which is the case on my home machine, and the key did not exist. |
||||||||
|
|
|||||||
Office without Outlook is not a proper Office product anyway :P Besides, that reg key doesn't work for Office 2007 either... |
||||||||
|
|
|||||||
This is just one of those issues, that seems like it should be a lot easier than it is. I've tried multiple methods and all of them seem to have holes. I think the GUID comparison method is as fool proof as it's going to get. Just another simple property that MS has made very difficult to find. |
||||||||
|
|
|||||||
Well not really as MS uses 0000000FF1CE for Exchange and SharePoint crap as well. Granted you won't find those on Workstations very often but SharePoint explorer and other Client and SBS stuff you do... |
||||||||
|
|
|||||||
But thats why the second segment is also checked. if $s="0011" or $s="011D" or $s="0012" or $s="0013" or $s="0014" or $s="002F" |
||||||||
|
|
|||||||
indeed. |
||||||||
|
|
|||||||
How do you know those segments will always be correct? Well batch wise I found a more dependable way for office versions, just the 32/64 bit thing for office I haven't figured out yet (just for the sake of doing it in batch, kix is easier off course). Code: @ECHO OFF FOR /F "tokens=3*" %%A IN ('reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Winword.exe" /v Path') DO SET answer=%%A %%B echo %answer% | findstr Office11 if errorlevel 1 ( GOTO :12 ) ELSE ( GOTO :office11 ) :12 echo %answer% | findstr Office12 if errorlevel 1 ( GOTO :13 ) ELSE ( GOTO :office12 ) :13 echo %answer% | findstr Office13 if errorlevel 1 ( GOTO :14 ) ELSE ( GOTO :office13 ) :14 echo %answer% | findstr Office14 if errorlevel 1 ( GOTO :END ) ELSE ( GOTO :office14 ) :Office11 MSG * Found Office 2003 GOTO :END :Office12 MSG * Found Office 2007 GOTO :END :Office13 MSG * Found Office 2010 GOTO :END :Office14 MSG * Found Office 2013 GOTO :END :END pause |
||||||||
|
|
|||||||
Quote: How do you know those segments will always be correct? because that's how office installs? the appPath you are reading might exist in windows vista. or might not. should not exist in anything earlier. and you are still looking for an office application, not office. so if you have custom install with word excluded because the installer hated it, your script would not see office. now, I know my sku matching is not complete and I might improve it or just put a disclaimer that office older than 2007 is not supported. the point still does come back to the "boys and girls" comment earlier. if it supposedly is so easy, why it takes many brains and days and still isn't done reliably? and if we turn this around, it took me the whole 30 minutes to write an udf, test it and post it... well, maybe closer to an hour. I would say the UDF was thus easier and simpler than "simple batch script" |
||||||||
|
|
|||||||
Originally Posted By: Lonkero Quote: How do you know those segments will always be correct? because that's how office installs? the appPath you are reading might exist in windows vista. or might not. should not exist in anything earlier. and you are still looking for an office application, not office. so if you have custom install with word excluded because the installer hated it, your script would not see office. now, I know my sku matching is not complete and I might improve it or just put a disclaimer that office older than 2007 is not supported. the point still does come back to the "boys and girls" comment earlier. if it supposedly is so easy, why it takes many brains and days and still isn't done reliably? and if we turn this around, it took me the whole 30 minutes to write an udf, test it and post it... well, maybe closer to an hour. I would say the UDF was thus easier and simpler than "simple batch script" Yeah, not so much, you forgot 008B for instance. The App Path I am reading has existed since Windows 98, so no worries there. If the Office installation does not contain Word, then we are by your definition not looking for an Office Suite at all, just loose applications :P Didn't take many brains or time really, just saw this as something funny to do in the off minutes I had today and yesterday to brush up on my batch scripting. All in all I used in total maybe 30 minutes. Besides, 64-bit office is a hack anyway. |
||||||||
|
|
|||||||
Finding the 32-bit vs 64-bit is very doable in batch and I've not tested but I have to believe that either my code or Arends code for that works in batch. As far as finding the actual version of Office I never said that. |
||||||||
|
|
|||||||
Maybe it's time we put this thread to rest. |
||||||||
|
|
|||||||
the difference between loose applications, like you are testing against and office is that office, when installed, does have OFFICE installed. you can omit programs from the installation and those keys won't be there. you can't omit office key, as it is what is installed. you still can buy stand alone office products. I have no system setup like that so I do not know if office keys are omitted then. but if they were, my udf would work correct, as no office was installed. your batch would fail as it would report office installed when only certain component was there. what comes to the app paths... I stand corrected. Learned something today. oh, and the sku's on the bit check udf have been updated. edit: I am all for ending the debate. I did (and still do) have an issue how a certain remark implied on a kixtart board that the job at hand would be somehow easier/simpler/better if I would have had brains to do it in a batch instead. |
||||||||
|
|
|||||||
Comment was not directed specifically at anyone. There was already discussion and no one at the time had provided any code so I said that a folder could be checked in batch (meaning that if batch could do it then KiX could as well and probably easier) and I still say it can be checked with batch if wanted. Is it the best method - NO and I don't believe I or anyone else said it was the best method. Only said that batch could check that folder and I still say it can. The UDF you provided Lonk is certainly a much more robust and appropriate coding to check on that. /End for me... |
||||||||
|
|
|||||||
All I wanted was to prove it could be done in batch. Which works to an extend, as you (Lonkero) pointed out, it's never a sure shot, and your UDF is when it comes to Full Office products. As far as putting this argument to rest, hell I haven't seen this board so alive as I did these last couple of days |