hello, all. Must Windows system locale(or say, system codepage, 1252, 936, 950 etc) be system wide? You know, in Windows 2000 ~ Windows 7, changing the system codepage in Control Panel requires a reboot to take effect.
I'd like to know whether I can have per-logon-session locale setting or even per-process locale setting? That will ease debugging program running with different locale.
BTW: I found GetCPInfo() Win32 API but no corresponding SetCPInfo, sigh.
Yes, the system locale is the whole system, but users and processes/threads can change their own locale.
The thread local can be set using SetThreadLocale().
Anything else is not in the remit of your program to change.
Related
I'm working on a Perl script that needs to do a few system calls to obtain some system data. In order to parse the output of those calls reliably on any computer, I need to be sure the output of the call is set to English.
The problem I'm facing is that, for example in my PC, I get localized output from those commands. My Windows is setup in Spanish so, calls like systeminfo return data in Spanish.
Is there a command (or something else) I can run in a command call to make all system calls act like if the system was in English always, without having to modify anything in the system configuration?
Thanks in advance for your comments.
NOTES for bounty: The answer to this problem must not interfere with the system in any way. It should be a way to obtain english answers from system calls/commands that works in any machine without modifying its configuration, registry or else.
This solution allows you to make Command Prompt act in english. It does alter some registry keys but it also changes them back if you want. You can run the same commands that they put in the .bats to make the system go to english and them go back to localized.
If you're trying to run commands that require adminsitrator privileges, then you can include these calls in your program without problems.
HTH
I think the WMIC command is your best best. It has been a standard feature of Windows since Windows XP.
WMIC has full access to the Windows system (subject to user permissions, etc.), and has a locale option that selects the locale in effect (for the command) from the installed language packs.
The locale is selected from the list here.
To get the current username using US English (if it's available) you'd use wmic /locale:ms_409 netlogin get name
Through the WMI interface, you may not even need to localise the results (i.e.: with sufficient care, you may just get the raw data).
Linux operating system identifies files by looking at its magic number at the starting of the header. How does windows do it ? Does it also have some kind of magic number mechanism or does it only rely on the file extension ?
It relies only on the extension, as provided by the filesystem; the contents of the file are not examined. See e.g. this article - it talks about Windows XP, but AFAIK the general behavior is shared by all released versions of Windows so far: http://support.microsoft.com/kb/307859
all dos base application experts here is one thread i am creating.
i would like your opinion for this issues
i found one problem in windows xp or any windows system higher to windows 98
i have a dos base application which runs perfect on windows 98 but when i am running it on windows xp or other system it is showing me following error message
16 bit Ms-Dos Subsystem
An application has attemped to directly access the hard disk, which cannot
be supported. This may cause the application to function incorrectly.
Choose close to terminate the application
as i can run it by pressing ignore but want to remove this error message
second thing i found is dos base printing
printing is not working properly
as it prints some part then it pause for some time and then resume printing
so how to solve these problems.
An application has attemped to directly access the hard disk, which cannot be supported.
This error means exactly what it says. Older versions of Windows including 95/98/Me gave DOS programs full control over the system, meaning they could access hardware as they wished -- while this maintained compatibility with older programs, it could also cause the entire OS to crash if this one program did something wrong.
The Windows NT family (including XP and all newer versions) runs DOS programs in an NTVDM (NT virtual DOS machine) which does not have direct access to hardware, and any attempt by programs to access such things will cause the program to be terminated. Of course, you can ignore the error, but your program will likely not work correctly.
I need to setup a script in group policy that we be used in different regions of the world. Are environmental variables such as %ProgramFiles% language specific? I'm hoping that a script of %ProgramFiles% can be used both in spain and france even though their language is setup for the specific regions.
Thanks
No. They are not language specific.
When you use %ProgramFiles% the operating system will check in Windows registry where %ProgramFiles% maps to. This mapping is done during Windows installation and therefore using the placeholder %ProgramFiles% you'll have a language/country agnostic solution.
No, but do watch out. I encountered a application that looked in "c:\Program Files" (hard coded, apparently). Tried to run it on a German (maybe it was French? Don't recall) version of Windows. "Program Files" is something else in German - I don't recall what, but it didn't parse as expected and of course the program failed.
Is there a way that I manually have a user look up the current Codepage and locale of their windows OS? Is there a registry setting that stores that information?
It would also be useful if the technique worked all the way back to Windows 2000.
The Win32 GetACP() function works back to Windows 2000 to find the ANSI code page.
The GetLocaleInfo() function works also back to Windows 2000. Call it with a Locale parameter of LOCALE_SYSTEM_DEFAULT (or LOCALE_USER_DEFAULT, etc.)
If your question is not how you can get this data programmatically, but instead how a non-programmer can look up this info, then you probably want to post the question on ServerFault which is the right spot for questions like that.