Arrow symbols missing from console font

[emendelson]

Environment (please complete the following information):

• OS: macOS 12.6.1
• Winery version: 2.9.1.5
• Master Wrapper version: 2.9.1.5
• Engine version: WS11WineCX64Bit22.0.1
• Hardware:
• Application/Game Name

Describe the bug

I managed to wrap a Windows console (text-mode) app (actually an old DOS app wrapped in a 32-bit launcher called msdos.exe) so that I can run it in Wineskin. The interface uses the right-pointing arrow symbol (character 1A in standard DOS fonts) to indicate which item in a list is selected. Under Wine, this symbol doesn't appear and and empty box appears instead.

To Reproduce
Download the app here and launch it. The empty box appears to the left of item 1 on the opening menu.

https://www.dropbox.com/s/np6sei2juu0ul7g/Ptr60.app.7z?dl=1

Expected behavior
An arrow (character 1A) appears where the empty box is.

Screenshots
Here are screenshots of the menu running in DOSBox and in Wineskin:

LastRunWine.log

I hope it's OK to post a ZIP of the log in order to save space. I don't think it provides any useful information.

LastRunWine.log.zip

Additional context

It would be nice to replace the console font with something like Lucida Console, but I've never been able to do that.

Incorrectly filled out issues will be close without notice!

[emendelson]

Additional note: I figured out how to change the console font. Install Consolas from Winetricks. Then, in the registry, find HKCU\Console\C:_windows_system32_cmd.exe and change the FaceName string value to Consolas. Unfortunately, this still doesn't produce the arrow symbol. And the same thing happens when you install and use Lucida Console.

EDIT: Maybe Wine simply doesn't display the control characters in a console font (the first thirty-two characters)? Perhaps this needs to be fixed upstream?

EDIT2: I've posted question in the WineHQ forum: https://forum.winehq.org/viewtopic.php?t=37173

[Gcenx]

I’d have assumed installing native fonts would have resolved the issue, most of the wine devs don’t really check the Winehq forums, an issue wouldn’t be valid there due to not being based on upstream wine but winecx.

It might be possible to report this issue to CodeWeavers, I’d recommend using my wine-crossover package via brew for this instead since that’s a straight source built without extra patches/hacks.

What’s this “msdos.exe” launcher you’ve mentioned?, this could be a candidate for another winetricks verb.

[emendelson]

Was online when you posted, so here's a quick answer.

First, could you spell out what you're suggesting I should do with wine-crossover? Is it that I should try to run my app in wine-crossover, and then report the issue to CodeWeavers? If so, I'll go ahead and do it.

Next, about msdos.exe (links below). It's a console app that you run like this under Windows:

msdos.exe c:\path\to\16bit.exe

and the 16bit.exe runs more or less as if it's running in an old machine. It works only with text-based DOS apps, and doesn't work with anything complex, but I've been able to use it for a lot of things. The best part is that you can run

msdos.exe -cFilename.exe c:\path\to\16bit.exe

and you get a 32-bit executable named Filename.exe (or whatever) that contains the 16-bit exe and is therefore portable, though in some cases I've found that I need to have the original 16-bit exe in the same folder with the wrapped 32-bit one.

The full syntax appears when you run msdos.exe without a parameter. Some 16-bit apps need the -n parameter to work correctly.

I learned about it from this fork (not currently maintained):

https://github.com/cracyc/msdos-player

and I now use the original:

http://takeda-toshiya.my.coocan.jp/msdos/index.html

There are many binaries in the download. You should be able to use the i486-32bit version with anything, but the best thing is to find the smallest and fastest version that works with your executable. This is often the i86-32bit version.

With the app that I posted here, I found that I needed to launch the wrapped 32-bit exe from a batch file in Wineskin. I couldn't get it to launch directly. But maybe there's way around this.

EDIT: Here's a wrapped version of the old ASCII utility that displays the current character set:

https://www.dropbox.com/s/sh4swfwmt1igz4u/Ascii32.7z?dl=0

If you run this from a Wineskin command prompt, you'll see that the control characters don't appear, no matter which font you're using.

[Gcenx]

First, could you spell out what you're suggesting I should do with wine-crossover? Is it that I should try to run my app in wine-crossover, and then report the issue to CodeWeavers? If so, I'll go ahead and do it.

Yes that’s what I’m suggesting, that’s a straight source build setup in the manner recommended by Brendan.

When installed via the brew cask command even calling wine just calls wine64

[Gcenx]

@emendelson

For my wine-crossover cask

brew install --cask --no-quarantine gcenx/wine/wine-crossover

For my custom winetricks formula/fork

brew install --formula gcenx/wine/winetricks

[emendelson]

@Gcenx - Yes, I figured this out a few seconds after posting my message, which is why I deleted it...!

Anyway, I installed your wine-crossover cask and your winetricks, and figured out where wine's drive C: was, and ran

wine c:\PTR60.bat

and got this result:

Because I can run the app in Wineskin Winery, I'm happy to live with the arrow key being replaced by an empty box...!