robertmo, i hope I may explain the case with Turkish layout:
When you specify some language code in keyb command without codepage DOSBox will select the first codepage defined for layout (for TR this is 857).
So after 'keyb tr' Turkish language and code page 857 are selected because all data are in dosbox.exe.
After 'keyb tr 437' DOSBox looks in data for TR layout and sees that it is described only for pages 857,853,858 and 850.
Hence there should be message 'No layout in tr for codepage 437'.
But here is an old bug in DOSBox: codepage displayed is not the page you try to set, but the current page of DOSBox. (Try 'keyb tr 850' and 'keyb tr 437' - and you will see the same message with another wrong codepage.)

BTW, 437 page is used as default when no language and page (or wrong ones) are set in config. If you set keyboard layout to auto (DOSBox default) then DOSBox tries to guess language from windows default keyboard. And if guess is successful then for some languages codepage is set to 437 (gr, sp, su, fr, it, nl, br, ru, sv, ur, sg, sf).

no it doesn't. it is a dosbox bug. Type: keyb tr keyb tr 437 and you will see the buggy message […]
Show full quote

no it doesn't. it is a dosbox bug. Type:
keyb tr
keyb tr 437
and you will see the buggy message

Wow what a huge bug, the error message has a wrong codepage when you
load other stuff before. There's no layout for 437.

wd should confirm whether he manually set it to particular layouts only, or tries to set it to every layout.

Can you reformulate so it makes sense, please?

I suppose D-Fend does this:
loads keyboardlayout="layout" from dosbox.conf when dosbox starts and than makes keyb "layout" 437. This loads for some "layouts", (as a result some games/programs that use text mode from codepage 437 look properly) and no false/buggy error message is being displayed.
For some layouts 437 cannot be loaded (as a result some games/programs that use text mode from codepage 437 don't look properly) and false/buggy error message is being displayer.

But I suppose dosbox already does the same. So this logic is not needed in D-Fend and as a result false/buggy error message won't appear at all when dosbox starts. I just don't know whether dosbox uses the same logic (so that it works for every layouts that can use 437). Or dosbox has some layouts programmed the way that they are forced to use 437 (so there is a possibility that some layouts have been omitted, and they still use their default codepage, while they could use 437)

wd!
About auto mapping of codepages (three posts above): maybe it may be removed - for all mentioned languages (except UR) default codepage is 858 (808 for Russian) which is presented in dosbox executable and may be loaded. For UR (Ukrainian) there is no layout for 437, so this mapping is also meaningless. 808 (as in Russian) would be better choise. (848 is more better, but is not preloaded)

loads keyboardlayout="layout" from dosbox.conf when dosbox starts and than makes keyb "layout" 437.

Dunno what it really does, but that's basically what the =auto is for as it
forces cp 437 IFF it's available (most compatible) and otherwise uses the
first thus preferred codepage of the layout, unless somebody claimed that
everybody uses another codepage in his country by default.
auto is only available for keyboardlayout= and covers a subset of the windows
layouts that seem to have a sensible representation as dos layout.

808 (as in Russian) would be better choise

Several games are incompatible with non-437 codepages so the default
auto selection will always force 437 if possible.

no it doesn't. it is a dosbox bug. Type: keyb tr keyb tr 437 and you will see the buggy message […]
Show full quote

no it doesn't. it is a dosbox bug. Type:
keyb tr
keyb tr 437
and you will see the buggy message

I played around with this, and the command 'exit' did not worked, because keyboard printed 'exit' w/o the point onto the i.

After typing 'exIt', the cmd worked... 😀

So?

turkish language has got two i. one is with a dot and the other one is dotless. the one with dot you get with "alt gr" (and the large one with alt gr+shift)

Yes, and works just fine in dosbox.

Thanks robertmo for the nice description about it, these are the words I looked for to describe. 😀

After this long discussion first of all thank you to all of you for this many information about the DOSBox keyboard layout system. I'm now using the values from the keyboard.txt from robertmo (updated version of the file) and an extended version of the codepages list from skatz (extensions also due to robertmo). The DFR installer (and update installer) will copy the FreeDOS cpx files to the DOSBox folder when installing (or updating) DOSBox now. With these files DOSBox is able to support a much wider range of keyboard layouts and codepages. At the moment the codepage default values list is just longer; in 0.9.2 I will change the codepage default values list to work like the keyboard layouts list. The entries in the list will be for example "437 (United States)" instead of just "437" then. But because I want to finish 0.9.1 as soon as possible (to fix the bugs from the long list of known bugs in 0.9.0) this will come not before 0.9.2.

Some words about how DFR tells DOSBox which keyboard layouts, codepages and what ever to use: The conf files used for calling DOSBox can be viewed at any time right from the context menu of each profile. Even more the profile editor has a "Show conf file" option so you can see the results of changes in the dialog immediately. DFR is using the "keyboardlayout=" key from the [dos] section to tell DOSBox which keyboard layout to use. Because there is no similar key for the codepage it's adding a "keyb <layout> <CP>" line to the [autoexec] section (so the "keyboardlayout=" list is redundant). And just before this is going to confuse anybody: The "default" line in the keyboard layouts list is not a DOSBox keyboard layout. This is a DFR value which means that DFR will use the default keyboard layout defined in the active DFR language file when starting this profile.

And last but not least:
D-Fend Reloaded 0.9.1rc3 is out now. I really hope everything is fine with this release now, so I can release 0.9.1 by the end of this week.

Plans for the next releases:
D-Fend Reloaded 0.9.2 is intended to come with DOSBox 0.74. Additionally some smaller things (which do not require new language strings) will be improved in 0.9.2. The next big release with many new features should be ready by summer this year.

I have just released D-Fend Reloaded 0.9.1. You can download it from the project download page as usual. Version 0.9.1 fixes all currently known bugs and includes the new Brazilian Portuguese and Turkish language files.

The next step will be D-Fend Reloaded 0.9.2 which will be released shortly after DOSBox 0.74. As the main feature this service release will come with DOSbox 0.74 but will also improve the codepage selection in the profile editor any may bring some improved checker for program updates. The next big release will be 1.0 which should be there by summer this year. On the D-Fend Reloaded beta versions homepage you can find a list of planned feature for this release.

Hope this is appropriate, I really don't mean to interfere your discussion and announcements, but let me say just this: D-Fend Reloaded kicks ass! I like this amazing DOSBOX frontend sooo much. It got so many features and also works with ScummVM and even can handle windows games and other emulators. Boy, I can't imagine living without this cute lil devil.

Thank you guys for your effort,
Thank you Alexander, you're a genius!

Hi, ... Alexander

I use your = D-Fend Reloaded, "v0.9.1 release", D-Fend Reloaded PortableApps package".

-----------------------------------------------------------------------------------
I have found that =

DOSBos priority (background), when set to "Pause", dont work.

Extras | Edit Multiple Profiles | Dosbox settings | DOSBos priority (background) = when i set it to "pause" and press the, "Ok" button it dont change the value.

in example it configure to =

[sdl]
priority=highest,highest

In example = It keep the old selection inside "Profile Editor of a game| Dosbox priority background, radio button.

---

Hi sst,

I can confirm this problem. There is a bug in the multiple profiles editor. The foreground priority value is read from the selection box and stored the right way but the value for the background priority is not read the right way from the selection box. This will be fixed in 0.9.2.

BTW: I have just finished one really great new feature which will already be actived in 0.9.2 because there are no new language strings needed for this. The search box will be much more powerful in 0.9.2. You can connect multiple strings by "and", "or", "|", "||", "&" or "&&", use "not" operators ("not", "-" or "!"), check for special values of properties, use brackets and also quotes for strings containing spaces. So you could enter

1"Commander Keen" Year<=1990

to look for the first Commander Keen episodes.

1Commander Keen

(no brackets) would list all Commander Keen profiles but also a profile named "Commander something Keen" (implicit "and" between "Commander" and "Keen") while

1Commander or Keen

also would list Doszip Commander.

1Commander -genre=File

again wouldn't list Doszip Commander, because it has "File manager" as genre. ("=" is not interpreted as "must be equal" but as "must contain".)

... The main thing I'm waiting for 0.9.2rc1 still is DOSBox 0.74.

Alexander wrote:

... The main thing I'm waiting for 0.9.2rc1 still is DOSBox 0.74.

Sure it comes soon? I wouldn't wait for that... 😉

Thanks for this great frontend! I use windows 7 and it is nice that D-Fend adds itself to the Startmenu/Games menu but it will not start from there. The shortcut in startmenu/D-fend is OK.
I use a regular user and UAC is on.

Hi Sladi,

I have just tested the Game Explorer integration and for me it's working. For making this thing work for you I would need some more information how to reproduce this bug. (But saidly I cannot tell you what information.)

Adding the Game Explorer integration to the installer was quite tricky perhaps something got wrong during your installation. You could try to uninstall and reinstall D-Fend Reloaded. (Not just installing DFR over an existing installation. Normally there is no need to uninstall DFR before installing a new version but in this case uninstalling first could be a good idea, because the installer will create a Game Explorer record only if there isn't already one.) Perhaps this helps. You can keep your user data folder during uninstallation so your games and settings should not be changed/deleted during this.

Hi Alex,

I tried tu reinstall D-Fend but it didn't help. Unfortunately I didn't look before but there are some permission differences between D-Fend and other games. I use a regular user, not the administrator account which is created after setup of Windows. (When I want to install something, I have to type in the admin password and it installs.)

I looked in properties of the shotcut:
Under the details tab the link to the shortcut is different. D-Fend has 'c:\programdata\microsoft\...' while others are 'c:\users\sladi\appdata\roaming\microsoft\...'.
The owner is Administrators for D-Fend, other shortcuts of games are owned by my user account.
As said before the permissions are different. 😀

Hi Sladi,

I'm using the Game explorer NSIS plug-in to add DFR to the Games Explorer. Because it already took me some days to find out the right resource format for the DFR icon to be used in the Games Explorer I really didn't like to analyse the whole plug-in code. I was just happy it was working. In the plug-in code the shortcut is created in $APPDATA\Microsoft\Windows\GameExplorer\. I can check if $roaming\microsoft\ is also working for me and if yes can add this in 0.9.2rc1 so it can be tested in a bigger circle.

But in general: I think working with two user accounts can cause problems. Modern Windows versions have UAC which is a good idea in my eyes. If you are using two independent user accounts I don't know what directory Windows tells the installer is the user data directory when dynamically switching the account. But we can test this out in the next beta/rc release of DFR.

BTW: After DOSBox 0.74rc1 was out I thought DOSBox 0.74 is quite close but at the moment nothing happens so I'm not going to wait any longer for 0.74. At the moment I'm planning to release DFR 0.9.2rc1 middle of march. (And 0.9.2rc1 will have most of the 1.0 features as hidden functions.)