This is an interesting one. I'm in the process of going from satellite DLLs to GNU gettext for translation and encountered this interesting problem. I have tried with hard coded string so gettext isn't the cause of it.
Here the strings are trated differently in the same menu. "Välj test" and "Stäng test" both contain the same character (ä), but one is displayed correctly while one isn't. When lookin in debugger both strings look fine, but Spy++ confirms that one is wrong. No idea what's going n here.
I'm using MFC in C++ and use Visual Studio 2010 (it's an old project). It's set to Unicode.
Related
I'm utterly stumped, so what I'm looking for is a body of speculation. Or maybe someone actually knows what's going on.
I have a program written in VB6 which has had every user interface element font set to "MS Sans Serif, 7 point", in an effort to create an English/Turkish localization. The localized strings are compiled into the VB6 EXE, and there is custom code to do the hot-switching between languages.
The program reaches through COM to a .NET DLL assembly which carries a "tr" satellite assembly with it, so that is also in the mix.
With a clean test system set with the display language (NOT the non-unicode setting, the other, more general one) to "English" the software runs without problems.
When it is set to Turkish, the .NET Interop system returns "Run-time error '-2147024894 (80070002)' -- Automation error -- The system cannot find the file specified." as soon as (it appears) the .NET DLL is called. (EDIT: This may not be the .NET DLL. I've opened an incident with Microsoft for more information from a deep trace.)
Because this is a clean-system test, there were no diagnostic tools installed, but a trace with Sysinternals ProcMon failed to show me something I could recognize.
The question becomes: Is that the right tool to go tracing my obscure little "file not found" error? Are there better tools? What should I be looking for?
But most fundamentally, does anyone know what changes when the display language changes, that would cause either a VB6 EXE or an Interop DLL to fail?
(EDIT) -- I have now tested this with five different display languages; only Turkish is failing.
I bet you have an I (i) in there!
I don't know how you are loading your DLLs, or if you've changed just the UI Thread or the worker threads' culture to Turkish, so I might be off a little, BUT...
Double check any file loads, any paths, and strings of importance etc. If they have an i, I in them, and you are using case operations (to lower, to upper) it will all go wrong with Turkish language.
We had a similar issue with our .net app and it's a pain to fix and go round using a specific culture for some things, but you can't trust to upper or to lower and the turkish language!
good luck.
I cannot account for the source of this error. Instead, after removing an "AMUS" directive from the installer, the error no longer occurs after installation. According to Microsoft's summary of the problem after I did some testing and couldn't reproduce it any longer:
The theory is there was something wrong with your install package (MSI
packaged using InstallShield). You were using the “REINSTALL=AMUS”
install setting which is a dangerous setting because it allows for
‘file downgrades’. Newer files can be overwritten with older versions.
Likely there was a overwritten file with the wrong version and it
failed to load because the dependency was for a newer version.
So... I'm gonna mark this one as answered with this answer, and add a Windows Installer key to the question. Steer clear of "AMUS" when calling Windows Installer...
i'm running Boa Constructor, an old wxpython gui builder.
today, the program decided to play tricks and switched all its GUI from right to left.
far worse, when i'm editing text inside the program, each letter is reveresed.
What part of windows does font mirroring?
How to disable letter mirroring?
why a program i used for several years suddenly thinks i need spanish internationalization? nothing in my computer is set for spanish.
how can I program this behavior myself (i don't really care, just curious. any programming language solution is ok here)
i'm asking several questions together because it seems somehow related.
my settings:
windows xp, (English interface setup!)
python 2.5.4
wxpython 2.8.11
All other Windows programs are left to right,
regional settings are for hebrew, israel
I don't know what you did, but you might want to check out the following instructions for enabling RTL: http://www.tavultesoft.com/kb/?id=41 and then see if you can reverse it.
I know wxPython can do internationalization. See http://wiki.wxpython.org/Internationalization and http://wiki.wxpython.org/RecipesI18n for information on that. Basically it involves .po and .mo files, which I doubt you can accidentally create. That's a weird issue.
Another developer at work told me it wouldn't work for some reason specific to Visual Basic 6 applications.
But I think it should work as long as you include the correct DLLs and runtime files, isn't VB6 compiled to machine code?
EDIT: I just mean in general should it be possible. I'm going to actually test this out in a few days as long as nobody gives me a theoretical reason it won't work.
EDIT 2: I think the developer was referring to P-code, which vb6 can optionally compile to instead of binary which runs under a virtual machine similar to (or the precursor of) the .Net framework.
I've tested a large VB6 app in Wine under Ubuntu. Event the msi installer worked fine. Had some troubles with low-level implementation details (e.g. in NM_CUSTOMDRAW on CDRF_NOTIFYITEMDRAW phase the hDC text is not transparent by default as in Windows common controls). So yes, even heavily subclassed stuff works. I just had to iron those minor glitches.
Here is a function that checks if app is running under wine
Property Get IsWine() As Boolean
IsWine = (GetProcAddress(GetModuleHandle("kernel32"), "wine_get_unix_file_name") <> 0)
End Property
Take a look at this http://appdb.winehq.org/objectManager.php?sClass=application&iId=7361
It looks like you can get most VB6 programs to work.
I have a desktop program I downloaded and installed. It runs from an .exe file.
Is there some way from the .exe file to tell what programming language was used to write the program?
Are there any tools are available to help with this?
What languages can be determined and which ones cannot?
Okay here are two of the sort of things I'm looking for:
Tips to Determine Whether an App is Written in Delphi or Not
This "IsDelphi" program by Bruce McGee will find all applications built with Delphi, Delphi for .Net or C++ Builder that are on your hard drive.
I use WinDowse (a small freeware utility written in Delphi) to spy the windows of the program.. for example if you look at the "Class" TabSheet you can discover the "Class" Name of the control..
For example:
TFormXX, TEditYY, TPanelZZZ for delphi apps
WindowsForms10.XXXX.yyy, for .NET apps
wxWindowsXXX for wxWindows apps
AfxWndXX for MFC/VC++ apps (I think)
I think this is the fastest way (although not the most accurate) to find information about apps..
I understand your curiosity.
You can identify Delphi and C++ Builder apps and their SKU by looking for a couple of specific resources that the linker adds. Specifically RC Data\DVCLAL and RC DATA\PACKAGEINFO. The XN Resource Editor makes this a lot easier, but it might choke on compressed EXEs.
EXE compressors complicate things a little. They can hide or scramble the contents of the resources. Programs compressed with UPX are easy to identify with a HEX editor because the first 2 sections in the PE header are named UPX0 and UPX1. You can use the app to decompress these.
Applications compiled with .Net aren't difficult to detect. Recent versions of Delphi even include an IsAssembly function, or you could do a little spelunking in the PE header. Check out the IsManaged function in IsDelphi.
Telling which .Net language was used is trickier. By default, VB.Net includes a reference to Microsoft.VisualBasic, and VCL.Net apps included Borland specific references. However, VCL.Net is defunct in favour of Delphi Prism, and you can add a reference to the VB assembly to any managed language.
I haven't looked at some of the apps that use signatures to identify the the compiler, so I don't know how well they work.
I hope this helps.
First, look to see what run time libraries it loads. A C program won't normally load Visual Basic's library.
Also, examine the executable for telltale strings. In most executables, this is near the end. If the program uses string constants, there might be a clue in how they are stored.
A good disassembler, plus of course an excellent understanding of the underlying CPU architecture, can often help you identify the runtime libraries that are in play. Unless the exe has been carefully "stripped" of symbols and/or otherwise masked, the names of symbols seen in runtime libraries will often provide you with programming-language hints, because different languages' standards specify different names, and vendors of compilers and accompanying runtime libraries usually respect those standards pretty closely.
Of course, you won't get there without knowledge of the various possible languages and their library standards -- and if the code's author was intent to mask the information, that's not too hard for them to do, either.
If you have available a large set of samples from known compilers, I should think this would be an excellent application for machine learning. I believe so-called "supervised learning" is relevant here. Unfortunately I know next to nothing about the topic—only that I have heard some impressive results presented at conferences.
You might dig through the proceedings of the Working Conference on Reverse Engineering to see if anyone else is interested in this problem.
Assuming this is an application for Windows...
Does Reflector recognize it as a .NET assembly? Then it's MSIL, 99% either VB or C#, but you'll likely never know which, nor does it matter.
Does it need an intrepreter (like Java?)? Then it's Java (or whatever the interpreter is.)
Check what runtime DLLs it requires.
Does it require the VB runtime dlls? Congratulations, VB from VisualStudio 6.0 or earlier.
Does it require the Delphi dlls? Congratulations, Delphi.
Did you make it this far? C/C++. Assume C++ unless it requires msys or cygwin dlls, in which case C has maybe a 25% chance.
Congratulations, this should come out correct for the vast majority of Windows software. This probably doesn't actually help you though, as a lot of the same things can be done in all of these languages.
IDA Pro Free (http://www.hex-rays.com/idapro/idadownfreeware.htm) may be helpful. Even if you don't understand assembly language, if you load the EXE into IDA Pro then its initial progress output might (if there are any telltale signs) include its best guess as to which compiler was used.
Start with various options to dumpbin. The symbol names, if not carefully erased, will give you all kinds of hints as to whether it is C, C++, CLR, or something else.
Other tools use signatures to identify the compiler used to create the executable, like PEiD, CFF Explorer and others.
They normally scan the entry point of the executable vs the signature.
Signature Explorer from CFF Explorer can give you an understanding of how one signature is constructed.
It looks like the VC++ linker from V6 up adds a signature to the PE header which youcan parse.
i suggest PEiD (freeware, closed source). Has all of Delphi for Win32 signatures, also can tell you which was packer used (if any).
I've inherited a ASP/VB6 code base (not my forte... yet) and I'm trying tease it apart to figure out the cause on an error message I'm receiving when running the app.
I've traced it back through an event that is being raised in on of my classes. Is there away in windows I can search the bulk of the code base for where it is being consumed?
Ctrl-F (and selecting Current Project) has not sufficed.
The linux geek in me is saying dump it to a insert distro box and just grep for the sucker. But there's got to be some way in the IDE to do it... right?
But there's got to be some way in the IDE to do it... right?
No. There are some plugins for the IDE, such as the MZ Tools that might help. Otherwise, just use the find tool from the Windows command line. Not nearly as comfortable as using grep, of course.
If you have any new version of VS (2003,5,8) installed, just use the "Find in Files" feature and point it at the VB6 folders.
Other than that, most "notepad" replacements (textpad, notepad+) offer a "Find in Files" as well.
Check out http://www.mztools.com/index.aspx
MZ-Tools 3.0 is a freeware add-in for Visual Basic 6.0, Visual Basic 5.0 and the Visual Basic For Applications editor.
It is essential for anyone still working with VB 6.0
It has an enhanced find feature as well as a calling Procedure similar to .net Find usage.
I have a large legacy code-base in VB6 which needs maintenance from time to time and I have used Microsoft Desktop Search on my local copy to help find variable and method names across the code files.
Also Grep is available for Windows.