File differences - windows

I have two notepad files.
One created in Windows 7 and another in Windows 10.
But both have different size (even same content) and somehow different 'format' that make my other program read both differently.
How do I check the differences? How can I make notepad that same regardless the Windows version?
Both file just have the word DATA

It looks like Encoding.
Windows 7 is saving as ANSI, while 10 is saving as Unicode (UCS-2 LE BOM), probably.
May help you: Changing the Default Ansi to UTF-8

Related

Encoding of an EXE program

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.

Delphi 2007 compilation with codepage parameter and teamcity

I'm trying to compile project wrote in Delphi 2007 with parameter --codepage:1252. At one machine with Windows 10 everything is ok and Spanish strings are displaying correct. When I'm doing the same on computer with Windows 8 parameter --codepage:1252 nothing change.
I need this because on computer where it's not working I have teamcity agent.
Has anyone similar problem? Or it is possible to achieve proper displaying Spanish characters on non-unicode application without changing it in windows property which required system restart and it's problematic for teamcity server.
EDIT:
On both computers I have set Polish language for non-unicode application and:
Windows 10 - compile with Spanish characters, copy exe file to Spanish PC and there is no Spanish characters.
Windows 10 - compile with Spanish characters and --codepage:1252 parameter set in dproj "1252", copy exe file to Spanish PC and Spanish characters are show correct.
Windows 10 - compile with Spanish characters and --codepage:1252 parameter in command line using dcc32.exe, copy exe file to Spanish PC and Spanish characters there is no Spanish characters.
Windows 8 - compile with Spanish characters, copy exe file to Spanish PC and there is no Spanish characters.
Windows 8 - compile with Spanish characters and --codepage:1252 parameter, copy exe file to Spanish PC and there is no Spanish characters.
What is the difference between compiling by Delphi and using dcc32.exe it should be the same output because Delphi use dcc32 in the same way, I can see it in output.
UPDATE:
After more test I have conclusion:
From Delphi IDE compiling with "--codepage:1252" and all files have ANSI format it's work. When I change to UTF-8 wont work.
From command line don't work in any cases and combination.
Delphi 2007 is the last version of Delphi that still uses an Ansi-based RTL/VCL. The native GUI components use the OS's default Ansi codepage. So it does not matter if your source code is encoded in Latin1/Spanish (which is what the --codepage:1252 parameter is telling the compiler) if your GUI cannot display Spanish data correctly on a non-Spanish machine.
As dummzeuch mentioned, your source code should be saved as UTF-8 instead of Latin1/Spanish. But if you want to display Unicode data at runtime from an Ansi-based executable, you will have to convert your data to Unicode and use 3rd party Unicode GUI components, such as the TNT Unicode controls. Also see Handling a Unicode String in Delphi Versions <= 2007.
Otherwise, bite the bullet and upgrade to Delphi 2009 or later, which use a native Unicode-based RTL/VCL. Delphi has been a fully Unicode product since 2008, it is time to ditch ANSI.
You could, on the computer where it works correctly, change the file format to UTF-8 and save it (I'm not sure whether it is possible to do that automatically for all files in a project. Then it should work on any computer, regardless of its codepage.
To change the file format, use the context menu of the editor window.

Working with UTF-8 encoded TCL files on windows

We try to convert the source files of a TCL/TK application to UTF-8, because this is the default charset of the plattforms we use for development (Linux and OSX).
Our problem is now that windows uses "cp1252" as system encoding, and because of this displays labels and buttons with (for example) german umlauts wrong.
The only solution we found yet would be to add "-encoding UTF-8" to all "wish" calls and "source" commands.
(There is also "encoding system UTF-8", but the documentation says that you shouldn't use it because of problems with system calls)
Is there a way to tell TCL that it should use UTF-8 as default encoding for all source files, or maybe another solution for this problem?
The solution suggested in the TCL chat:
Create and use your own versions of "open" und "source" (like "my_open" and "my_source") which then call the original commands with "-encoding utf-8"

Console isn't showing pretty characters in Shell

I want to write some pretty, special characters taken from Web in my Shell Console with echo command. I want to write, for example, ▲ character, but it shows me ��� character. How can I solve the problem? Thanks!
I am using Ubuntu 64 bit also. You should check your terminal type and what kind of character-set does it supports. Take a look at this
and this
You need to make sure you character sets match and that you are using the correct terminal emulation. This can be set on both the Linux side or using your terminal client software.
e.g. ANSI, VT100, Linux
Character sets like UTF-8 does include symbols.

Windows XP - Restricted File Renaming

When I try to rename some files via Windows Explorer (I am using Windows XP), I come across some files on very rare occasions whereby I can only add a few characters to before I can progress no further.
For example, if I want to rename:
AFileName.doc
to:
thisIsANewVersionOfFileName.doc
I am only able to get as far as:
thiAFileName.doc
I have experimented with a few 'affected' files and have deduced the following:
the length of the name makes no difference;
it apparently affects any file type (.doc, .xls, .pdf, etc);
each file is located in a different directory
file which are both 'shallow' and 'deep' in their respective directories can be affected;
each file does not have any restrictions, such as read-only, password protection from within its respective application (Word, Excel, Adobe Reader).
I would like some suggestions as to what could be causing this as I need to rename said files but am unable to do so due to this problem.
Many thanks.
Well after a quick googling I found this:
Point A: The limit of 255 characters for Windows XP or 260 character limit for Windows Vista applies to the entire filepath and not just the filename.
Limitations With Long File Names on Windows [Must Read for Podcasters]

Resources