NTLinks + NTLinksMaker: NTFS links creation and information
Moderators: Hacker, petermad, Stefan2, white
milo1012,
Thank you for your note and links, some of them are new to me. It would be great to have documented and really working way to solve this problem (original problem was that Korean symbols are too small, screenshots are here).
I already use MS Shell Dlg but it is clear that it doesn't work well in this case: it doesn't substituted with Korean font (so Korean symbols are always small regardless of font size set in a dialog template, screenshots are here) and it is impossible to set OS-dependent font size (while there are font aliases like MS Shell Dlg, fixed font size must be embedded into a dialog template).
First of all I tried to add a localized copy of dialog but it isn't good to include almost identical copies with different fonts only (it is hard to edit them and also they require additional resource space).
Currently I find that taking dialog font from system window the most straightforward way of solving the problem. If I read the font, I copy it and use in my dialog, or I just show unchanged dialog from resource. This way allows dynamically resizing dialog depending on a particular Windows settings, also it allows setting a font that is really used. But if there really is a way that I overlooked, please let me know.
Thank you for your note and links, some of them are new to me. It would be great to have documented and really working way to solve this problem (original problem was that Korean symbols are too small, screenshots are here).
I already use MS Shell Dlg but it is clear that it doesn't work well in this case: it doesn't substituted with Korean font (so Korean symbols are always small regardless of font size set in a dialog template, screenshots are here) and it is impossible to set OS-dependent font size (while there are font aliases like MS Shell Dlg, fixed font size must be embedded into a dialog template).
First of all I tried to add a localized copy of dialog but it isn't good to include almost identical copies with different fonts only (it is hard to edit them and also they require additional resource space).
Currently I find that taking dialog font from system window the most straightforward way of solving the problem. If I read the font, I copy it and use in my dialog, or I just show unchanged dialog from resource. This way allows dynamically resizing dialog depending on a particular Windows settings, also it allows setting a font that is really used. But if there really is a way that I overlooked, please let me know.
It really is no news that i18n isn't easy, especially in case of CJK systems.
The best way to treat font names and sizes is to consider them as another localizable resource
I've seen a lot of programs that use it.
If you want a good localization you can't refuse it.
Otherwise you'd just have to live with that minor cosmetic issues.
I'm honest: I don't like your obsession for keeping executables down to a few kB
by using WinAPI functions only and not using a CRT at all,
since it can have some security and functionality traps,
and you obviously never heard of MinGW, which always links to msvcrt.dll ...
But anyway,
what exactly is the problem with adding another DIALOGEX template for such a language?
It'd be just ~500 Bytes from what I can see.
http://mihai-nita.net/2007/05/03/how-to-localize-an-rc-file/
It might look different (Tahoma), but if you don't have font substitutes in that case I think it'd be worth it.
and temporarily set the system locale to that language (and region).
It's kinda "hackish" and is probably not the ultimate way.
Wouldn't be surprised if some virus scanners may give you some false alarms due to using hooks.
2sheppaul
Do you really except to have all UI programs to look like the system?
I mean it sometimes bothers me too that some programs can't display according to system settings,
but it's more like a cosmetic issue in most cases (at least as long as you can still read the text).
To quote this page:MVV wrote:It would be great to have documented and really working way to solve this problem
The best way to treat font names and sizes is to consider them as another localizable resource
Why?MVV wrote:I tried to add a localized copy of dialog but it isn't good to include almost identical copies with different fonts only
I've seen a lot of programs that use it.
If you want a good localization you can't refuse it.
Otherwise you'd just have to live with that minor cosmetic issues.
Seriously ?MVV wrote:Also they require additional resource space
I'm honest: I don't like your obsession for keeping executables down to a few kB
by using WinAPI functions only and not using a CRT at all,
since it can have some security and functionality traps,
and you obviously never heard of MinGW, which always links to msvcrt.dll ...
But anyway,
what exactly is the problem with adding another DIALOGEX template for such a language?
It'd be just ~500 Bytes from what I can see.
http://mihai-nita.net/2007/05/03/how-to-localize-an-rc-file/
At least give DS_SHELLFONT and/or "MS Shell Dlg 2" a try.MVV wrote:I already use MS Shell Dlg but it is clear that it doesn't work well in this case
It might look different (Tahoma), but if you don't have font substitutes in that case I think it'd be worth it.
I could also do some tests, but I'd need to get a copy of some CJK OS to test it, though since vista one could just install some language packs in Windows UpdateMVV wrote:if there really is a way that I overlooked, please let me know
and temporarily set the system locale to that language (and region).
To say it again:MVV wrote:I find that taking dialog font from system window the most straightforward way of solving the problem
It's kinda "hackish" and is probably not the ultimate way.
Wouldn't be surprised if some virus scanners may give you some false alarms due to using hooks.
2sheppaul
Do you really except to have all UI programs to look like the system?
I mean it sometimes bothers me too that some programs can't display according to system settings,
but it's more like a cosmetic issue in most cases (at least as long as you can still read the text).
TC plugins: PCREsearch and RegXtract
milo1012,
sheppaul,
Please try to edit older NTLinksMaker version (w/o font setting support). You should change DS_SETFONT style to DS_SHELLFONT in a dialog resource and/or change font to MS Shell Dlg 2 (only first change, only second and both ones) while keeping original font size. However I don't think it will change anything but let's give it a try as milo1012 suggests.
I know that each resource may have many language-specific copies, and I don't need to edit RC-file, I can make it within IDE. But localization via copies of dialog template is limited, user can't chose which one to display. My localization is loaded according to INI setting and all dialog controls are translated in WM_INITDIALOG, so my dialog template even doesn't contain any text, only empty controls. As I said, having ten templates that differ only in font setting would require to keep ten similar resources in the file and it would require ten dialog templates in order to change something in the dialog. Also new language would require editing resources and not just creating a new text file. Finally, if user set large font (because it is more comfortable for him), dialog template won't use it.what exactly is the problem with adding another DIALOGEX template for such a language?
On the contrary I don't like modern trends to made huge programs with no functionality. I agree that serious project requires CRT, Boost etc but I like when tiny tools are tiny (e.g. when a bunch of little tools take less space than TC itself).I'm honest: I don't like your obsession for keeping executables down to a few kB
I know about MinGW but I don't like it.you obviously never heard of MinGW
Tahoma is a bad choice in our case because it doesn't support Korean, and font linking keeps symbols small while English letters grow.At least give DS_SHELLFONT and/or "MS Shell Dlg 2" a try.
There are no any hooks here, just searching for a window and sending a message to it. But you're right, some virus scanners are really dumb.Wouldn't be surprised if some virus scanners may give you some false alarms due to using hooks.
sheppaul,
Please try to edit older NTLinksMaker version (w/o font setting support). You should change DS_SETFONT style to DS_SHELLFONT in a dialog resource and/or change font to MS Shell Dlg 2 (only first change, only second and both ones) while keeping original font size. However I don't think it will change anything but let's give it a try as milo1012 suggests.
sheppaul,
I tested it again with different fonts set via system Personalization applet, and there is no way to change dialog font there (I only can change font for message boxes which SystemParametersInfo returns, but it is not the font that is used for dialog controls).
Please open the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes with regedit. You'll find MS Shell Dlg item there which sets exact font that is used for dialogs. It is interesting which font is used for it in your Windows, also it is interesting what will happen if you'll set it to your desired font and restart Windows.
However it is still a question how to get font size for dialog controls. Please test beta 242 with changed substituted font.
I tested it again with different fonts set via system Personalization applet, and there is no way to change dialog font there (I only can change font for message boxes which SystemParametersInfo returns, but it is not the font that is used for dialog controls).
Please open the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes with regedit. You'll find MS Shell Dlg item there which sets exact font that is used for dialogs. It is interesting which font is used for it in your Windows, also it is interesting what will happen if you'll set it to your desired font and restart Windows.
However it is still a question how to get font size for dialog controls. Please test beta 242 with changed substituted font.
I think the explanation for the Font mess can be found in this excellent discussion
In short: You have no choice but to either live with non-system-look on your programs for Vista+,
or you try some magic to overcome it at least partially, but no all-in-one solution exists.
I wonder why sheppaul was never confronted with such programs (Dialogs) before, as there are tons of programs out there that don't use Vista+ styles.
But if you want complete Internationalization you need to live with that.

I didn't say I'm against keeping programs reasonably small, but that restricting yourself to pure WinAPI calls can have some serious flaws.
(not to mention that API calls are slow)
There are other possibilities, like using the MS platform SDK to link against msvrt.dll (msvcrt_win2000.lib) to avoid embedding a CRT,
or the mentioned MinGW that you can instruct to use a minimalist runtime, etc.
In short: You have no choice but to either live with non-system-look on your programs for Vista+,
or you try some magic to overcome it at least partially, but no all-in-one solution exists.
I wonder why sheppaul was never confronted with such programs (Dialogs) before, as there are tons of programs out there that don't use Vista+ styles.
That's the Achilles' heel when using ini-based config: you can't just control all UI stuff with it.MVV wrote:Also new language would require editing resources and not just creating a new text file.
But if you want complete Internationalization you need to live with that.
maybe quote the right partMVV wrote:On the contrary I don't like modern trends to made huge programs with no functionality. I agree that serious project requires CRT, Boost etc but I like when tiny tools are tiny (e.g. when a bunch of little tools take less space than TC itself).

I didn't say I'm against keeping programs reasonably small, but that restricting yourself to pure WinAPI calls can have some serious flaws.
(not to mention that API calls are slow)
There are other possibilities, like using the MS platform SDK to link against msvrt.dll (msvcrt_win2000.lib) to avoid embedding a CRT,
or the mentioned MinGW that you can instruct to use a minimalist runtime, etc.
Using SetWindowsHookEx / CallNextHookEx is enough for some scanners.MVV wrote:There are no any hooks here.
TC plugins: PCREsearch and RegXtract
Yeah, that's a really wonderful answer, thank you! And it is interesting that I came out to same idea: call SystemParametersInfo and send WM_SETFONT for all dialog childs. However additionally I need to set font size for dialog template in order to scale it.milo1012 wrote:I think the explanation for the Font mess can be found in this excellent discussion
Also it noticed that I've missed a member added to the structure filled by SystemParametersInfo since Vista, so now I set ncm.cbSize to sizeof(ncm) - sizeof(int) and it works in older Windows versions!
Anyway I need to program GUI by myself, also system calls remain unchanged. So the only thing that CRT may give to me here is memory management (well, maybe secure formatting functions but API ones also good enough if you know their limitations).milo1012 wrote:There are other possibilities, like using the MS platform SDK to link against msvrt.dll (msvcrt_win2000.lib) to avoid embedding a CRT,
or the mentioned MinGW that you can instruct to use a minimalist runtime, etc.
Maybe. But hook is used here for adding additional buttons to confirmation windows, and it only used in NTLinksMaker, not NTLinks. Anyway, both NTLinks and NTLinksMaker do much more harmful things: e.g. they call DeviceIoControl (for creating junctions) and enable a privilege (SE_CREATE_SYMBOLIC_LINK_NAME for creating symbolic links)!Using SetWindowsHookEx / CallNextHookEx is enough for some scanners.
BTW it was enough to call ClipCursor (even not to call it, it was simply enough to have this function in an import table) from my TCFS2 tool to make it suspicious for ESET antivirus, and contacting with its developers didn't help, they were too lazy to do something with false alarm. Interesting that same ESET didn't find anything suspicious in TCFS2Tools.dll when I moved same code to it (it was a code for moving TC separator, and clipping used to prevent user mouse movements for a moment).
Nope, as long as we Koreans can read the text as you mentioned.I mean it sometimes bothers me too that some programs can't display according to system settings,
but it's more like a cosmetic issue in most cases (at least as long as you can still read the text).
The problem is it's really hard to read a text with a small font size. The size below "9" looks abnormal in Korean. Many programs does use a font size "8" or even below 7. It makes Korean chars crushed....
Simply I don't use such tools. If I have no choice but to use it, I don't use a translated version. The reason why bugging MVV is that I'd like to introduce it to my people having a difficulty with english.I wonder why sheppaul was never confronted with such programs (Dialogs) before, as there are tons of programs out there that don't use Vista+ styles.
I'm using win 8.1 x64.Please open the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes with regedit. You'll find MS Shell Dlg item there which sets exact font that is used for dialogs. It is interesting which font is used for it in your Windows,
MS Shell Dlg - Microsoft Sans Serif, 42 (font size)
MS Shell Dlg 2 - Tahoma, 14
Latest NTLinks Maker version is:
NTLinksMaker Beta 262
It has better error handling with hardlinks and new dir creation. Test option FontSize removed.
NTLinksMaker Beta 262
It has better error handling with hardlinks and new dir creation. Test option FontSize removed.
I've finally released NTLinksMaker 1.0.5.262 and put it to totalcmd.net. 
NTLinksMaker at wincmd.ru / NTLinksMaker at totalcmd.net

NTLinksMaker at wincmd.ru / NTLinksMaker at totalcmd.net
Here is the UNTESTED German.lng file, but I played around and got only the English dialogues (although my system language is German).
Peter
Code: Select all
; NTLinksMaker 1.0.5.236, hardcoded messages
[NTLinks Maker]
; English messages (1252) - be careful with format parameters like "%s" and "%X"
1=&Ja
2=&Nein
3=&OK
4=Abbre&chen
5=Ja zu &Allem
6=Nein zu Allem
7=&Alle ignorieren
8=Erstelle &Link(s) für %d Objekt(e) als:
9=Anzahl der Ebenen, die als &Ordner dupliziert werden:
10=Fehler beim Erstellen des Link:\n%s\n\nZiel des Link:\n%s\n\nFehlerbeschreibung:\n
11=Die Erstellung symbolischer Verknüpfungen benötigt erweiterte Rechte (Administratorrechte).
12=Ihr Windows scheint symbolische Verknüpfungen nicht zu unterstützen.\n\nMöchten sie stattdessen Junctions (Abzweigungspunkte) und Hardlinks (harte Links) erstellen?
13=Erkenne relativen Pfad von Einträgen mit Verwendung dieses &Basispfades:
14=Linkt&ypen
15=Hardlinks und Junctions
16=Symbolische Verknüpfung, wenn notwendig
17=Nur symbolische Verknüpfung
Last edited by Peter on 2015-06-21, 10:59 UTC, edited 1 time in total.
TC 10.xx / #266191
Win 10 x64
Win 10 x64
Peter,
Only Russian language is detected automatically (by locale identifier), other languages must be specified in NTLinksMaker.ini/NTLinksMaker64.ini file:
I'll add this information to Readme.
Only Russian language is detected automatically (by locale identifier), other languages must be specified in NTLinksMaker.ini/NTLinksMaker64.ini file:
Code: Select all
[NTLinks Maker]
Language=German
And/or to "NTLinksMaker64.ini".MVV wrote:Peter,
....other languages must be specified in NTLinksMaker.ini file:...
The Error-dialogue seems a bit strange if the display of Win 7 is set to 125%:
Image: http://www.pixhost.org/show/2698/28274917_ntlinkmaker.png
TC 10.xx / #266191
Win 10 x64
Win 10 x64
That's correct, I've edited my post above.Peter wrote:And/or to "NTLinksMaker64.ini".
Well, I would say it looks as it should look, and in looks so in any scale. Buttons are all visible, this is the major thing. Background is drawn by Windows so when I enlarge dialog to add a button, it isn't drawn there.The Error-dialogue seems a bit strange if the display of Win 7 is set to 125%:
I've received your mail message, thank you for your translation!
Last edited by MVV on 2015-06-21, 11:03 UTC, edited 1 time in total.
sheppaul,
I tried another way to get font size because message boxes and dialogs should be different. Please test this version, it shows a message on start with detected font size:
https://yadi.sk/d/wqjvvGIKhSXes
Will it detect that you have font size 9 in your language? And it is interesting at all if it will produce font size same as in Windows dialogs (e.g. Run one) with different font scale values: 100%, 125%, 150%...
I tried another way to get font size because message boxes and dialogs should be different. Please test this version, it shows a message on start with detected font size:
https://yadi.sk/d/wqjvvGIKhSXes
Will it detect that you have font size 9 in your language? And it is interesting at all if it will produce font size same as in Windows dialogs (e.g. Run one) with different font scale values: 100%, 125%, 150%...