Windows and Fonts, the simple solutions.

[raithe]

I've had a problem with most *band variants and vanilla under XP since its release nigh ten years ago and as I understand it these issues still exist in Vista & 7. The problem is fonts. Once you run ANY windows *band build that uses bitmap fon to display text that fon file becomes locked by csrss.exe and bound to that one executable. The only way to unhook it is to reboot. This means that if you have say vanilla and NPP set to both use 12x24 and you launch V you have to reboot or switch fonts to play NPP. Between the many variants and subwindows there's not enough fonts available. That's the problem as it stands going all the way back to 2.7.x

There are however two simple solutions to this problem. What puzzles me is why almost no maintainers implement them.

1) Build native windows console versions like most other roguelikes. It works fine, no problem. ibm builds used to be common but everyone stopped releasing them.

2) Do like a couple of variants (Hellband springs to mind) and add support for System Fonts in the win builds.

I don't use subwindows much myself, so for a long time I just ran ibm builds since I prefer the console anyway for roguelikes. Then everyone stopped releasing them and I began to wonder why this bug was never fixed. I guess the reason it puzzles me is no other roguelike but *bands suffer from this issue, and its not exactly a new thing or difficult to repair.

[Nick]

I've had a problem with most *band variants and vanilla under XP since its release nigh ten years ago and as I understand it these issues still exist in Vista & 7. The problem is fonts. Once you run ANY windows *band build that uses bitmap fon to display text that fon file becomes locked by csrss.exe and bound to that one executable. The only way to unhook it is to reboot. This means that if you have say vanilla and NPP set to both use 12x24 and you launch V you have to reboot or switch fonts to play NPP. Between the many variants and subwindows there's not enough fonts available. That's the problem as it stands going all the way back to 2.7.x

There are however two simple solutions to this problem. What puzzles me is why almost no maintainers implement them.

Speaking for myself, it's because I had no clue this was the problem - I have put quite a bit of time into diagnosing it experimentally

I think a lot of *band players like subwindows, so your option 2 looks like a good one.

Are System Fonts Unicode (I'm guessing yes)? And if so, how is the new UTF-8 support going to interact with this?

[raithe]

Windows supports unicode fonts definately. The implementation in Hellband is derived iirc from angbandTK. It basically seems to implement the standard windows font selection api from the way it looks but I haven't looked at the source for that in depth. I'm not too good with windows api's or C (or unicode come to that). I'm more a Pascal/DOS type. I would assume however that it would handle it pretty much the way windows does anything else with unicode. The implementation being an older one however it may need to be updated, not sure.

I think the root problem here is the method angband uses for fonts. Something in the loading process or something that doesn't jive with the Windows API. I say this because you can: -> install the font files from Sangband (for example) to the Windows font directory using the standard font install method,-> fire up Hellband, -> switch to system fonts and choose a font you just installed. It will work. Then launch cthangband 4.1 (which also supports system fonts though I think the method is different) choose the same font and its ok.

Again I'm just going by basic observation here, but that seems to be it in a nut shell. If the problem existed under win9x I could just hook angband and csrss to softice and give you some more precise answers. Sadly this is strictly an NT thing, and the world seems to have decided that Ring 0 debuggers (like so many other useful computer things) are antiquated and useless.

[ekolis]

That's odd - doesn't each Angband variant contain its own font folder? Why would locking a font on one variant prevent some other variant from using its own copy of that font? Or is this not a filesystem lock you're talking about?

[raithe]

Maybe that's part of the problem. A lot of games use their own fonts which they keep in the games folder structure. But these aren't used as windows fonts, they're rendered in opengl or whatever. Programs that use custom fonts, like office, install those fonts to the windows/fonts/ folder. Maybe the issue is in the way windows handles fonts. Perhaps it indexes them by name, not location. Assuming they're in the font folder where they should be. Then it can't find them. Don't know. I know csrss.exe has them locked though. You can check it in process explorer by searching for handles.