I haven't found any answer or clarification on this subject in the internet.
I have a very old program (over a decade old) for windows (portable executable exe). It displays data in my language (hebrew) and uses cp1255 encoding (old, today is obsolete due to UTF-8). now, the thing is - it only displays data on specific types of computers, so long I've only been able to run it on:
x32 bit windows 7
My question is whether I can get it to work on x64 bit windows 7 encoding. On the x64, the program actually launches, but it displays a whole lot of question marks and jibrish instead of hebrew. I conclude this is due to the encoding.
Sidenote: The program loads info to display from unidentified files (their extensions are fabricated and I have tried to recover and types but so long not very successful). They too, have data in hebrew using the old CP1255 encoding and also has some machine code in it (opened it with a notepad, weird symbols along with text)
I've come up with 2 possible solutions for now:
Either somehow make the program support UTF-8, translate the exe to UTF-8 (probably requires special programs or reverse engineering)
OR
make my OS support the old encoding (cp1255 / windows-1255)
I haven't been able to execute either of them.
If you have any more solutions to tackle this problem or know how to solve it with one of the possible solutions, I'd be glad!
-yuval.
Edit: By the way - I have the language installed. I am using hebrew as one of the keyboard languages and I surf the web with it.
You may have already gone down this path, but have you given a try to running in compatibility mode on your x64 machine? Right click on the executable or shortcut, open properties, and go to the compatibility tab. There is a troubleshooter there that could help.
Related
Good morning!
Recently I installed gvim on windows 10 and started vimtutor. My home language is Russian and vimtutor was translated by default.
After entering lesson 2.1 I found out that I can't use dw to delete words. Using this command I can delete 1 or sometimes 2 letters in a word. I can't delete the whole word as vimtutor says. Example of text from vimtutor:
Несколько слов рафинад в этом предложении автокран излишни.
For testing purposes I inserted some text using latin symbols and tested dw. Everything deletes correctly.
So when I use gvim in windows 10 I can't complete vimtutor because it works incorrect with non-latin characters. I found a similar question here Similar question The answer was "don't use cyrillic characters". Unfortunately, the answering person didn't fully understood the problem. The question was about editing non-latin text and the answer was about using non-latin symbols in command mode (which is not a problem for me).
I continued my research and found out that console version of vim in windows 10 has the same problem: I can't edit texts with cyrillic symbols.
Then I loaded my OpenSUSE i3 system and launched vimtutor there. Suddenly, all commands work correctly and I can complete vimtutor (even if it mostly contains cyrillic characters).
Do I miss some setup steps in Windows or is it a bug? Why dw don't work only on non-latin words and only in Windows?
After creating issue on Github (https://github.com/vim/vim/issues/8588) I got a respond from habamax about the problem. It seems that in old versions of Windows vim utf-8 is not used by default. Editing vimrc or using nightly build (as habamax suggested in the issue) solves the problem.
A Visual FoxPro 9 program I support is not working on ONE SPECIFIC copy of Windows 10. Other users are working in Windows 10 without issue, but for this one user, all of the form labels are not displaying. Text boxes still work fine.
The program uses some ActiveX controls that are built in Delphi 6, and those are exhibiting similar behavior. Both pieces of the program are also sometimes crashing with divide by zero errors (again, only on this one specific install -- all other users from WinXP to Win10 are running fine).
I've tried compatibility mode and admin mode. I've validated that the install is complete and that the files are not corrupt. Any idea about what might cause this type of issue?
Wondering if you have checked that one user's display settings against the others. I ran into a situation where some text wasn't showing properly and I had to play with those settings.
Just got a notification from StackOverflow that this question has been viewed 1000 times, and I realized that the more complicated answer was never posted.
While Hank's suggestion was helpful for a few people, other people continued to crash even after playing with display settings, scales, zooms, and other things. While doing a screen share with one of the people who were crashing, I started comparing the screens that had text with those that did not. The fonts that were showing up were ARIAL, while the missing text was in VERDANA.
Windows 10 did in fact have Verdana installed, but FoxPro and Delphi couldn't display anything in Verdana. Eventually after a bunch of poking around, I found that Windows 10 had a new (possibly 4k compatible font?) for Verdana and forcing a reinstall of the older font package fixed the problem. Not a great "long term" solution, but people aren't crashing anymore... and we're rewriting the entire system for the web.
I am making a retro text adventure game in Turbo Pascal that will be played in MS-DOS, and I want it to be in the COM file format. I've looked it up and have found nothing on this subject. If you can help me that would be greatly appreciated.
Something other than that, whenever I try to run my program (compiled into EXE) from DosBox it can't run due to "This program cannot be run in DOS mode". Is this because I'm using Turbo Pascal 7 and need to downgrade? Thanks a lot of you can figure this out.
Set your TP7 to target dos, not windows. Note that you might have an Windows only TP product (also known as TPW)
COM files will still be out of your reach, but at least DOS exe files should run in dosbox. Keep in mind that COM files have a 64k limitation, and therefore are of limited interest.
Free Pascal is working on a DOS16-bit Dos compiler that can generate com files directly from (64-bit) Windows, and while it is working, it is not released yet.
I have some customers/candidate who complained that my program doesn't work on their Windows 7 64 bit version (confirmed with screenshots). The errors were strange, for example:
in the trial version i am
getting a error message whenever i
click on \"mark\" \"delete\" \"help\".
error msg is: Access violation at
address 0046C978 in module
\'ideduper.exe.\' read of address
00000004
windows 7 ultimate 64bit. i7 920
#2.67GHz 9gb or ram
'Mark', 'delete' and 'help' are just standard TToolButton on TToolbar.
The other example is failing to get a thumbnail from IExtractImage.
I have told them to try Compatibility mode but still doesn't work.
The problem is when I tested it on Windows 7 HP 64-bit on my computer (which I've done it before released it actually) it just works fine! So I don't know what causing it
Do you have any advice ?Are different Windows package (home basic,premium,ultimate,etc) treating 32 bit prog differently ?Are the newer version of Delphis (I use 2006) more compatible with 64 bit Windows ? Do I need to wait until 64 bit compiler out?
Thanks in advance
Your best bet in my opinion is to add MadExcept or EurekaLog or something similar to your application and give it to the customer to try again. MadExcept will generate log with stack trace, which will give you a clearer view of what is happening there.
To answer 2nd part of the question, 32bit Delphi programs work fine on 64bit Windows 7. I think it's more likely you have some memory management problems and the customer just happens to stumble upon them while you don't. Use FastMM4 to track those down.
Your applications is trying to access an invalid pointer. Changing environment may surface issues that are hidden in others. Check your application, and use FastMM + JCL+JCVL/MadExcept/EurekaLog to get a detailed trace of the issue. Some Windows APIs may have some stricter call requisites under 7 and/or 64 bit, but we would have to know what your app actually cals.
A free alternative to MadExcept is JCL Debug stuff. However it is less thorough and doesn't include the cool dialog box to send the stack trace to you via email, or as a file you can attach and manually email.
MadExcept is worth the money, and it is free for non-commercial use. You could try it first on your own PC, observe its functionality, and be sure it functions the way you want, and then buy it.
If buying Delphi is worth it (and it is!) then buying mad Except is a no brainer. But if you insist on rolling your own, JCLDebug (part of jedi code library) is also pretty nice.
Give them a stripped down version of your app and see when the problem goes away. I am betting it is your code as I never had any problems with my (hundreds of) W7/64 clients.
I'd be willing to bet it's an issue in your code. The reason it's failing on your customer's machine and not yours is that your machine probably has the default Data Execution Protection (DEP) enabled (which is turned on only for essential Windows programs and services), while your customer's computer is actually using DEP as intended (turned on for all programs and services).
The default setting (which is compatible with older versions of Windows, like 95/98/ME), allows software to execute code from what should be data segments. The more strict setting won't allow this, and raises a system-level exception instead.
You can check the settings between the two by looking at System Properties. I'm not at a Win7 machine right now, but on WinXP you get there by right-clicking on My Computer, choosing Properties, clicking on Performance Options, and then selecting the "Data Execution Prevention" tab. Find it on Vista/Win7 by using the Help; search for Data Execution Protection.
The solution, as previous answers have told you, is to install MadExcept or EurekaLog. You can also get a free version as part of JEDI, in JCLDebug IIRC. I haven't used it, so I can't vouch for it personally. I've heard it's pretty good, though.
If you don't want to go that route, set a breakpoint somewhere in the startup portion of your app (make sure to build with debugging info turned on). Run your app until the breakpoint is hit, and then use the IDE's Search->Goto Address (which is disabled until the breakpoint is hit). Enter the address from the exception dialog (not the one that's almost all zeros, but the 0046C978 address, prefixed with $ to indicate it's in hex) as in $0046C978. You'll probably end up in the CPU window looking at assembly code, but you can usually pick out a line of Delphi code of some sort that can sometimes give you a place to start looking.
In addition to all previous suggestions, I'll add the difference in accessing Registry under WOW64 compared to Win32. If your application is accessing Registry to read or write some settings, you should be aware of this. First, take a look at this and this page in the MSDN. On this page you will find 2 flags that determine the access you get to Registry from 32- or 64-bit application. KEY_WOW64_64KEY is the one that you should use.
In any case, I agree with others about using madExcept (or any other similar tool) to be able to find the exact cause of your problems.
Windows XP Embedded is missing the NULL or "NUL" device. For one thing, Visual Studio seems to require it and trying to build a project aborts with a PRJ0015 error.
Anyone know how to configure an XPe image to include support for the NUL device?
"Null Device Driver" is available in the XPe Target Designer, but it's normally hidden. Apparently each component has a visibility level, and if it's lower than that set in the Target Designer options (Tools->Options), it's hidden. Null Device Driver is at level 200, so I set the level to 100 and could see it and install it.
There's another important situation where you're going to want the NUL device: if you're installing some or all of the Cygwin UNIX solutions for Windows. In particular, if you're doing something like, oh, I don't know, to pick a completely random example, trying to put an SSH server on the damned thing so you can, just on a lark, say, log in and maintain it.
That's right-- Cygwin actually maps its UNIX /dev/null device to the Windows NUL device. You know, for maximum compatibility. Just in case the platform-specific implementation of IMMEDIATELY THROWING DATA INTO THE TOILET AND OBLITERATING IT, NEVER TO BE SEEN AGAIN, UNTIL THE HEAT DEATH OF THE UNIVERSE, happened to be novel and innovative.
While cygwin will INSTALL without NUL available, it will not, in fact, actually enjoy a typical work day. This is most evident the first time you try to launch a bash shell, and notice a slew of error messages about /dev/null resulting in no such file or directory errors. One presumes the device is perhaps actually just an NTFS link, but who knows.
In any case, the fix is to add the "Null Device Driver" component, helpfully located under Software -> System -> Other, a surprisingly small category which also contains such useful components as Internet Checkers, the Schedule Service Command Line Utility, the 1394 Kernel Debugger Support Library, EBCDIC support for Microsoft Bob, some cheat codes for Zork, and the code pages to say "(A)bort, (R)etry, (I)gnore, (F)ail?" in Muppet Swedish ("(B)ork, b(o)rk, bo(r)k, bor(k)?")
Hope this helps,
Matt "Breakpoint" Heck
Running Visual Studio itself on XP Embedded doesn't seem like it'd be supported. You should build on a full OS and then just deploy your application to XP embedded.