I'm trying to use FileGrep in a function to determine the state of service on the target machine. The function calls a wrapper application which then runs Microsofts sc.exe application to query the service control module regarding the named service. The output of this call is sent to a text file in the local temp folder. I then use FileGrep to parse this text file to extract the service state. This works fine on XP and English Vista systems but on Vista, Win2k3 server and later OS, the output of sc.exe is part localised. So on a Swedish system I get extended swedish characters. FileGrep cant read these as the extended characters seem to be mapped to a different font / codepage when read from the text file.
My question is, is there any way to force the codepage / fomt of a file opened using FileGrep?
Would it make more sense to use InstallScript's service APIs? In particular ServiceGetServiceState might do what you want without requiring you to parse output at all.
I don't see any way to influence the codepage used for reading from a file. It appears we support just binary, ANSI (ACP), and Unicode options (as discussed on OpenFileMode).
I tried the built in ServiceGetServiceState functions on Installshield 2008 and they didnt work on Vista. I assumed that behaviour would continue in Installshield 2009, so I abandoned that method and went for sc.exe instead. The help for ServiceGetServiceState and its related functions indicate that they are only compatible with OSs up to XP. Maybe I'll have to investigate using OpenFileMode and parse the file in code.
Ah, yes, we have a tracking number for fixing the Service* APIs to only require administrator privileges when the action they perform requires it. This number is IOC-000059857, and it has not been addressed yet as of IS 2010. You can see some more information with a possible alternative on the thread: http://community.installshield.com/showthread.php?t=169135
I managed to resolve my problem by forcing my wrapper app to output the captured sc.exe output as a Unicode encoded text file. When Filegrep read these files it handled the extended charatetrs corretly.
When my wrapper app used the default encoding there seemed to be some character mapping which broke things. Thanks for the pointer to FileOpenMode, that gave me the hint about forcing unicode encoding.
