I want to test my software works on Windows regardless of language. Is there a difference between a localised install Windows 7 and an install with the language changed by a language pack? Is it enough just change language packs to confirm my software works or do I need to install a localised version? In particular I want to be sure that the code page used by the API changes.
It's equivalent, you are perfectly safe using a language pack. I'm a bit concerned about your comment regarding code pages though--Windows 7 natively runs in Unicode (Windows 95/98/ME did not and relied on code pages, but this has changed from Windows XP) and it seems unthinkable nowadays not to develop in Unicode, or are you doing something very specific that requires you to use non-Unicode encodings?
If that clarifies things, on Windows XP and beyond, all the ANSI versions of the APIs (ending with a A) simply wrap the Unicode APIs (ending with a W), doing conversion to Unicode and back to ANSI on the way out.
Related
Similar to this question What programming languages are installed by default on Windows 7?. Is the environment any differnt for Windows 10?
For some programs like MS OFfice you get the VBA, Chrome you would get Javascript, if you activate the Bash for Ubuntu on Windows then you can get bash. Not sure if that is default.
In particular, if you didn't have administration rights over a Windows 10 laptop but needed a programming language... what could you use or do about it?
ie I wanted Ruby installed but I needed our tech team to help me. I want to avoid someone else with higher access but also not breach policy.
Out of the box no install solutions include:
(To be written using text file editing software like the preinstalled notepad)
Batch (.bat)
Visual basic script (.vbs)
HTML (.html)
CSS (^Use a style tag for the HTML doc)
JavaScript (.js)
Some quick gets include:
Bash (Ubuntu from Windows Store)
AutoHotKey (from autohotkey.com)
#Code (Windows Store. Apparently supports 12 different languages)
Hope this helps!
Edit: If you really wanna try, you can edit .exe files directly but yeesh.
Edit 2: repl.it is a website that lets you code in tons of different languages, possibly Ruby. With repl.it you can do all the things I've listed and more! (As long as you have alright internet.)
what could you use
You could use pretty much any languages. Any compiled executables looks the same to the OS as any other.
The only catch is that some languages' runtime libraries are quite big, so it's common for smaller programs not to include the entire language runtime and instead expects it to be preinstalled on the machine to keep its own download size small.
However, even high level scripting languages that requires huge runtime support libraries can often be packaged into standalone executable, so that you don't need to install the runtime yourself.
Ultimately it depends on what you wanted to do. If you wanted to just make simple scripts, probably .bat scripts will do just fine. If you wanted something simple and fast, then you can write native executable in C, otherwise if you want to do something a bit more complex and you're fine with the larger download size if you can keep your own program simple, or if you can later get admin to preinstall your preferred runtime on your target machines, then high level languages like Python or Ruby would be great options.
I am writing software (Delphi 2009 Unicode project) which depends on third party library (.dll).
The library is working fine in English language but when I switch the language of application to Russian some characters are not shown correctly. (I can see ?????).
(Application uses several languages - most of them is working fine but especially Russian customers can see this bug).
I found out when I run the software with AppLocale (Russian language) everything works fine.
Also if in Windows Regional settings I set Language for non-Unicode applications to Russian I can see the characters correctly.
How can I achieve the same with code?
As I do not have sources for the library I cannot modify it. I suppose I need to initialize my software the same way as AppLocale do.
Something like calling SetThreadLocale() in application to affect whole application - and also the library.
There is no problem to write C/C++/C# library if this cannot be achieved directly in Delphi.
I have been asked to write a (very) simple program for a set of Windows machines (XP I think) - so simple that the choice of language isn't really an issue. However, I want to be able to distribute a binary/script that will run straight away on the Windows machine, without the need to pre-install any interpretor or virtual machine. I'm developing on a Linux machine and I have no idea what languages Windows supports 'out of the box'. Can anyone advise?
For example
Perl would be great but I don't believe windows machines come with Perl pre-installed? Asking the user to install Perl to use my script is not acceptable.
I believe Python has the same problem? (although maybe I can use the PyInstaller? -- as in this question)
Likewise Java? Is the virtual machine pre-installed on most Windows distributions? (I understand it got removed after a dispute with Sun Microsystems?)
The only option I can think of so far is
c/c++ with MinGW cross-compiler.
While I'm happy to write the code in c++, I wanted to check my language options first.
The only scripting languages supported out of the box are the batch interpreter, vbscript and jscript. Other than that you are into compiled languages. A good option could be C# but make sure you target the .net version that shipped with XP.
Delphi and Lazarus/FreePascal generate native applications that don't even need on MSVCRT
Some of the other systems have requirements on relatively new MSVCRT versions that might be a burden on older windows versions.
However recent Lazarus and Delphi versions stop supporting windows NT4 and Win9x, with win2000 in a gray area (not supported but works afaik)
Having an internal win32/64 linker makes it also an excellent choice for crosscompiling from *nix to Windows.
I don't think that Java comes pre-installed on Windows.
I'm not using Windows for some years now, but if I correctly remember you can develop scripts with VBScript or JScript and deploy them without need for clients to install anything.
Any language which compiled to pure native assembly (without special run-time dependencies) should be fine. For example: many C variations (but not all), Microsoft Visual C++, Microsoft Visual Basic 6, OCaml, Haskell and more.
Requiring the .NET Framework (which gives you also C#, VB.NET and F#) is reasonable, and also JVM is pretty standard (and so you get Java, Closure and Scala).
I found out (though my other question) that my IME outputs Hangul Compatibility Jamo (U+3130 – U+318F) instead of regular Hangul Jamo(U+1100 – U+11FF).
So I tried asking a question in superuser about other IMEs, no replies yet.
Should I just convert it myself? What exactly does that entail? Is it too complicated? Any ideas on how to? Any help would be appreciated.
Language: Delphi
OS: WinXP
IME: Korean Input System (IME 2002)
There is no reason you could not write an interesting experimental editor control with its own built in Unicode Compose feature. However, before you did that, you might look for a way to change the configuration of the IME. This seems to be a really interesting corner-case you have to work with. I was already surprised about your other question - that Windows has the ability to handle Raw Input from keyboards.
I found that source code for something that says it is the Korean IME is available for Windows CE. You might learn something by studying it, even though it is for Windows CE rather than XP.
http://msdn.microsoft.com/en-us/library/ee491900.aspx
OK, so we're writing our MFC application to make use of the built-in localization support with satellite DLL's since MFC 7. Everything seem to be working fine, except that my Windows 7 Enterprise Edition install with MUI support and using a Swedish UI instead of an English UI still displays the English UI in our application.
The application uses Swedish as its default language, with an English localization DLL in the form AppNameENU.dll, so MFC is actually intentionally switching to English language under these circumstances, as if it's not caring for the user choice in the MUI-enabled Windows OS, and only the default shipping language of the Windows install?
From the MSDN page on this (the link above), I read it as MFC should actually take these settings into account though, but I'm not 100% sure. Can someone please clarify?
It's because the MFC support for language selection has a design bug: It will decide to load resources from the exe only if no DLL match user OR system language.
In your case: It sets up its (ordered) list of languages as such:
Swedish (User language)
English (System language)
Then it looks up your DLLs (Bug: only the dlls, not the exe!): No match for Swedish. But there's a match for English!
Solution: Use my CLanguageSupport class. It works fine even in your use case.
Feel free to use it. You'll need only a couple of minutes to incorporate it into your app and it uses the exact same DLL scheme as the one you already implemented. (Hint: Don't forget the step where you must get rid of the CWinApp::InitInstance() call!)
In addition, if you are interested (this is optional), you can get an automatic languages menu to let user pick his own preference in case the default is not what he wants.
And if you're looking for a great tool to help you manage your translations, think appTranslator ;-)
HTH,