Hello.

There is another bug (bug 4928) about charsets and Crt was added to bugtracker recently:

"Simply include "uses crt;" and your write() output is garbled. I use Russian language, win32, codepage 1251. Some symbols are substituted by question marks, some --- by other symbols. CRT docs don't mention it openly, some other unfixed bugs don't seem to state this exact problem."

I can add that in this case these problems can be solved by adding to the program

  SetConsoleCP(1251);
  SetConsoleOutputCP(1251);

from Windows unit.

Example that will work correctly:

uses Windows, crt;
begin
  SetConsoleCP(1251);
  SetConsoleOutputCP(1251);
  ClrScr;
  writeln('Hello World!');
  writeln('Привет, мир!'); //String in Russian, doesn't work correctly
without above trick even in Russian Windows
  readkey;
end.

It would be good to add a trick like this to win32 crt (i.e. set Windows default charset for console) as it would ease porting of old TP programs to FPC.

Was there an attempt to automatically convert source of dos program for TP with much system-dependance? Of course, there are places that can not be converted without hands (some VGA tricks etc), but it could be possible to highlight such places..

Does anyone know such a tool for legacy transformation?

Great!
I have posted that bug, it was found accidentally and was not important for me with new programs. However, your answer eases porting old programs!
Still, sometimes such tricks don't help: custom dos character tables require more attention when porting. (However, programs with such techniques are usually overhauled with far pointers, direct port accesses and interrupt calls. I didn't succeed in easy porting my favorite self-written computer game.)

.
.

It would be good to add a trick like this to win32 crt (i.e. set Windows default charset for console) as it would ease porting of old TP programs to FPC.

I'm afraid it's slightly more complicated than this. Older Windows versions (Win9x, WinNT 4.0) use different default codepage (charset) for console windows and for GUI ("OEM" versus "ANSI" codepages). Newer versions (Win2k+) use always the "ANSI" codepages (i.e. 1251 for Russian, 1250 for Central Europe, 1252 for Western Europe). No idea what WinME does. Anyway, you have to check the Windows version first...

Tomas

This is not important message.

I posted such a message as bug report 4986:
**********************
Running "fpc 1.pp" makes "1.exe",
running "fpc 1.pp." makes "1.pp.exe",
running "fpc 1.pp.." makes "1.pp..exe",
running "fpc 1.pp.........." makes "fpc 1.pp..........exe". **********************

Ok, it's not a big bug, but I've got answer: "Please use the mailing list for questions. The exe replaces the extension of the file. The extension is defined as everything after the last '.'"

I did not explicitly mention, that there were no files "1.pp..", "1.pp..." etc. The compiler processed the same file each time. It is in one way expected: under win32 files 1.pp, 1.pp.. etc are all (without tricks) the same thing: trailing dots do not matter. But: for the same source file (with the same name) I get different exe-s, without specifying output file name (by the way, object files and others are processed the same way).

It is not important, but obviously not very correct.

With some bug classification I wouldn't post it as "critical bug", I'd post it as "funny note". (I understand, that bug tracking system isn't installing itself and don't expect it to change in a matter of months.)

Sorry for inconveniences (laconic was I in bug report).