Closed Waitsnake closed 3 days ago
Waitsnake
commented
4 weeks ago
Saw in dosbox-x logfile that there are five unhandled IOCTL calls (52, C, F, F and F) and one INT10 Function CC00 not supported when I execute ND.exe . This maybe points to what functions are missing in dosbox-x to make this work.
MX9000
commented
3 weeks ago It may have a common cause with bug #4470 also apparently triggered by a problem with INT 10h emulation.
Waitsnake
commented
3 weeks ago I found out, that I can also re-create the same symptoms I have with ND in dosbox-x (2024.03.01) also in 'DOSBox 0.74 SVN'. When I remove or comment out the line "KEYB gr 437" in my autoexec.bat of 'DOSBox 0.74 SVN' I also see no custom fonts in ND. But as soon as I call KEYB later with either "KEYB gr 437" or "KEYB gr 850" the custom fonts in ND are back. But when I call another codepage like "KEYB gr 858" then the custom fonts are missing in ND again.
The same did not work dosbox-x (2024.03.01). There it did not matter if I call "KEYB gr 437" or "KEYB gr 850" and the custom fonts in ND are still missing.
Not sure why though and if dosbox-x changed something regarding KEYB and/or code pages 437 and 850 compared to SVN ? Can be only the detection in ND of the codepages is not working correct (by using some undocumented DOS and/or Video interrupt functions) or if load of custom fonts in general is not working for ND (maybe also by using undocumented DOS and/or Video interrupt functions).
I also tried another dosbox fork 'DOSBox Staging 0.81.1' in the meantime and it behaves like 'DOSBox 0.74 SVN' and also did not have the issue that dosbox-x (2024.03.01) has.
joncampbell123
commented
3 weeks ago INT 10 AH=CCh is a TSR for Toshiba laptops? http://www.ctyme.com/intr/rb-0519.htm
That can't be the reason it doesn't work.
joncampbell123
commented
3 weeks ago I am testing now with this version: https://winworldpc.com/product/norton-desktop/10-for-dos
joncampbell123
commented
3 weeks ago I see absolutely NO attempt by ND.EXE to change any character data whatsoever.
Waitsnake
commented
3 weeks ago I am testing now with this version: https://winworldpc.com/product/norton-desktop/10-for-dos
I got my ND for DOS version first also from the link you mentioned. But during install I selected "Color" mode already and my installer got stucked in dosbox-x. Then I found the version also on archive.org and downloaded the ISO (containing the disk images) and used this. https://archive.org/details/DOS-GUI-DOS-Norton-Desktop-v1.0-1992 But the installation stucked also during install. Looking backward maybe also bc I selected "Color" mode already and then it will already use the fancy updated graphic during install. I then installed the program on Dosbox SVN where "Color" mode during install worked and then I just copied the installed ND folder to my dosbox-x where it runs like I showed in my initial post with less graphic details then in Dosbox SVN or Dosbox Staging.
MX9000
commented
3 weeks ago @Waitsnake I noticed that the installer seems to freeze, but in fact it just pauses for a long time: over 5 minutes on my machine (3000 cycles). Trying the installation on an older version of DOSBox-X (2022.12.26), I noticed that the pause does not occur. However, the menu at the bottom of the screen appears in German even though the rest of the menus are in English.
MX9000
commented
3 weeks ago I compared the floppy images with DOS command “FC /B”: the winworldpc and archive.org versions appear identical. I tried again to install Norton Desktop in a clean installation of DOSBox-X 2022.12.26 and this time even the menus at the bottom of the screen are in English.
MX9000
commented
3 weeks ago I was able to get all the graphic characters in the latest DOSBox-X release (even the small icons of disks, folders, files) by starting a real DOS 6 (Italian) and changing the codepage from 850 to 437. With codepage 850 installed by default, I was getting graphic mouse pointer and characters except icons.
Waitsnake
commented
3 weeks ago When you say the latest release, did you mean the last one available release in git (2024.03.01) or did you build it in your own? And on what architecture and operating system did you run it? And what of the many versions of Dosbox-X did you use (especially Windows seems to have ton compiled with different compilers even).
I saw the issue actually on last git release 2024.03.01 first (dosbox-x-macosx-arm64-20240301150043.zip) and I run it on macOS with 14.4.1 (23E224) with an M1 processor that ist an Arm64 architecture. I also tried release 2024.03.01 for Windows (dosbox-x-winXP-2024.03.01-setup.exe) in Parallels Desktop before I opened this issue here and inside runs via a Hypervisor a Windows 11 for Arm64 direct on the M1 where Microsoft implemented x64 processor emulation.
Last week I also cloned the DOSBox-X repository to my Mac as it was trying some stuff out in the KEYB program. So that version I compiled was way newer as last release, but I still saw the ND issue there. After I read your comment I just pulled the latest commits that where created over the weekend and compiled it fresh on my Mac (for SDL2 btw, but for the official Mac release I tried both binaries SDL and SDL2) and still see the issue.
Waitsnake
commented
3 weeks ago I was able to get all the graphic characters in the latest DOSBox-X release (even the small icons of disks, folders, files) by starting a real DOS 6 (Italian) and changing the codepage from 850 to 437. With codepage 850 installed by default, I was getting graphic mouse pointer and characters except icons.
Oh and I have overseen that you run it on "a real DOS 6" what I don't do. 😅 I use the DOS enviroment and commands that dosbox-x provides directly, since I like to have an easy access to my data via a shared folder of my host operating system and I don't like cumbersome access to an internal hard drive image that those real DOS installations need. But when it works on a "real DOS" then the issue must be somewhere in the DOS enviroment and the DOS commands that dosbox-x provide directly. My biggest suspicion at the moment is the KEYB command implementation, but of course it could be also in one of the DOS(21h) or VIDEO(10h) interrupt handler functions.
MX9000
commented
3 weeks ago I ran the tests with the latest officially released version 2024.03.01 VSbuild 32 bit under Windows 10 Pro 64 bit.
Torinde
commented
3 weeks ago I like to have an easy access to my data via a shared folder of my host
The convertdrivefat option may help you for that when using a guest OS.
Waitsnake
commented
2 weeks ago I played a little with an example for TSR handling under DOS written in Pascal (original source from here) 2 weeks ago that can attach to different interrupts. When it registered a certain key combination (I changed it to trigger at 'left shift + ctrl' since on my laptop keyboard not have a 'Print Screen' key) it saves the screen and then paints the ASCII table and on ESC it restores the screen.
Activating this TSR under dosbox-x inside a running ND (with the issue and pure char mode) all looks quite normal:
But activating this TSR under dosbox-staging inside a running ND (without the issue and 'advanced graphics') you see they really change dynamically the character table. They use it kinda like the tiles on a gameboy game. They draw everything with changed characters in the table, even the mouse cursor that is over the letter S on the screenshot is drawn with two characters dynamically. With the example TSR you can see how the character table changes as you move the mouse cursor.
Here the 'graphics' mouse cursor as two characters zoomed to find it quicker.
It still not explains where the issue exactly is that ND has with dosbox-x, but it shows at least what kind of programming technique Norton used back then to "draw" in pure character/text mode.
The TSR example with my changes for key trigger as PAS file and also compiled EXE. TSR_EXAM.zip
joncampbell123
commented
2 weeks ago Is Norton Desktop writing directly to font RAM? I'm aware that DOSBox-X inherits the DOSBox design where if it knows that bitplane 2 is enabled, writes to text RAM are mirrored to an array that holds the EGA/VGA font RAM.
DOSBox-X inherits that mirroring, even though it could very well just read font data directly from the VRAM, bitplane 2, in text mode.
Waitsnake
commented
2 weeks ago I mean I don't know how many different levels of access to front RAM exiting? I saw them in debugger getting at least the pointer to the upper ASCII character table multiple times via "INT 10h AX=1130 BH=0" to get int 1F pointer (graphics character table). And for what asking for a pointer all the time if not writing something into? And if you look at ND with the running ASCII printer TSR example I posted in real time and then move this graphic mouse pointer around and see some characters in the ASCII table changing in realtime I really assume they do. However I found out today that access to font RAM was not the problem for ND.
When I saw your commit I was just in the middle of debugging ND on dosbox-staging and dosbox-x in parallel. I did this in the past with INT 10 and INT 21 already, but this time I explored INT 2F (DOS Multiplex Interrupt).
ND ask during start for the state of a ton of DOS drivers anddevices (e.g. Himem XMS driver, Windows 386 and much more) via INT 2F,0 (Get Installed State). Most of the calls had in both boxes the same register calls after until I found one call that did not and I simply changes the register result of dosbox-x to the result i saw on dosbox-staging for a couple of times until I saw a graphic cursor on the screen of dosbox-x!
The difference it in the return value of INT 2F AL=0 AH=17. Not sure why ND asked and why it is important for them?
According to "stanislavs HelpPC Reference Library" it is state of "17 = DOS shell". https://www.stanislavs.org/helppc/int_2f-0.html
But according to "Ralf Brown's Interrupt List" it is "MS Windows WINOLDAP - IDENTIFY WinOldAp VERSION". http://www.ctyme.com/intr/rb-4636.htm
Strange both sources are not in line here. 🤷
What ever it is, dosbox-staging returns here AX=1700 ("= 1700h if this version of WINOLDAP doesn't support clipboard") and dosbox-x returned AX=0101 ("<> 1700h AL = WINOLDAP major version
AH = WINOLDAP minor version"). And ND expected here AX=1700 to activate its fancy "advanced graphics".
See the "cmp AX,1700" after the INT 2F call:
I found the function in dosbox-x that coded and changed the return value quickly from 0101 to 1700 just to try it out.
diff --git a/src/dos/dos_misc.cpp b/src/dos/dos_misc.cpp
index 5239a4370..84952f39c 100644
--- a/src/dos/dos_misc.cpp
+++ b/src/dos/dos_misc.cpp
@@ -424,8 +424,8 @@ static bool DOS_MultiplexFunctions(void) {
// Special case for INSTALL/INSTALLD
if (((!strcmp(psp_name, "INSTALL") || !strcmp(psp_name, "INSTALLD")) && reg_sp >= 0xD000 && mem_readw(SegPhys(ss)+reg_sp)/0x100 == 0x1E)) return false;
}
- reg_al = 1;
- reg_ah = 1;
+ reg_al = 0x00;
+ reg_ah = 0x17;
return true;
case 0x1701:
if(control->SecureMode()||!clipboard_dosapi) return false;I compiled it and just run it free without any debugger and now ND 'advanced graphic' just works also in dosbox-x. 🤩
Waitsnake
commented
2 weeks ago I looked deeper into that code area around INT 2F AX=0x1700 that that does a blacklist handling for some programs that already get the return value 0x1700. Some tools of Norton Desktop are already included like NDD, UNFORMAT and UNERASE since they maybe were sold in a different bundle and someone else already fixed the return code for them.
But Norton Desktop comes with more tools that needed to be blacklisted too: NAV, NDCONFIG, VIEW, NMAIL, NM, SPEEDISK, SYSINFO, NDEDIT, SFORMAT, SMARTCAN, DISKTOOL and ZIP. And ND.EXE itself as main program has no psp name (empty String "" when INT2F is called) and needs a special case handling to be identified by psp size (22938) and psp type (0x4D).
I also saw that Norton Commander and its tools also has some of those 'advanced graphics' features (not so much as ND though) and they needed to be blacklisted too: NCMAIN, WPVIEW, NCEDIT, NCCLEAN, NCDD, NCSF, NCFF, NCNET and NCSI.
diff --git a/src/dos/dos_misc.cpp b/src/dos/dos_misc.cpp
index 5239a4370..5fbc4fd76 100644
--- a/src/dos/dos_misc.cpp
+++ b/src/dos/dos_misc.cpp
@@ -413,7 +413,12 @@ static bool DOS_MultiplexFunctions(void) {
case 0x1700:
if(control->SecureMode()||!clipboard_dosapi) return false;
{
- static constexpr std::array<const char*, 7> blacklisted {
+ static constexpr std::array<const char*, 28> blacklisted {
+ // ND tools (12)
+ "NAV", "NDCONFIG", "VIEW", "NMAIL", "NM", "SPEEDISK", "SYSINFO", "NDEDIT", "SFORMAT", "SMARTCAN", "DISKTOOL", "ZIP",
+ // NC and NC tools (9)
+ "NCMAIN", "WPVIEW", "NCEDIT", "NCCLEAN", "NCDD", "NCSF", "NCFF", "NCNET", "NCSI",
+ // other tools (including some ND tools: NDD,UNFORMAT,UNERASE) (7)
"DEFRAG", "DISKEDIT", "NDD", "NDIAGS", "UNERASE", "UNFORMAT", "WINCHECK"
};
char psp_name[9];
@@ -423,6 +428,8 @@ static bool DOS_MultiplexFunctions(void) {
for (auto prog : blacklisted) if (!std::strcmp(psp_name, prog)) return false;
// Special case for INSTALL/INSTALLD
if (((!strcmp(psp_name, "INSTALL") || !strcmp(psp_name, "INSTALLD")) && reg_sp >= 0xD000 && mem_readw(SegPhys(ss)+reg_sp)/0x100 == 0x1E)) return false;
+ // Special case for ND (uses empty psp_name)
+ if (!std::strcmp(psp_name, "") && (psp_mcb.GetType() == 0x4D) && (psp_mcb.GetSize() == 22938)) return false;
}
reg_al = 1;
reg_ah = 1;That increases the blacklist from 7 to 28 and 1 more special case and I hope I did not forgot any affected tool from Norton. If the blacklist keeps increasing, maybe it is better to do a whitelist for those SW that needs 0x0101 as return code instead of blacklisting those how need 0x1700 ?
joncampbell123
commented
2 weeks ago @Waitsnake I never thought about that! INT 2F AX=1700h corresponds to WINOLDAP clipboard functions.
So. that means you can get Norton Desktop to correctly show the font by adding:
[dos]
dos clipboard api=falseMaybe Norton coded their DOS program to care whether the Windows 3.1 DOS VM had clipboard functions enabled or not because the custom charset wouldn't translate properly if copied to the clipboard?
Or more likely, if the user used ND.EXE in a Windows DOS "box" and the user was using it windowed, rather than fullscreen, the custom font wouldn't appear properly because Windows uses it's own font to render text mode.
joncampbell123
commented
2 weeks ago This brings up an interesting question: Would it be possible to implement the clipboard API in a way that doesn't make DOS programs think they're running under Windows?
Or, since the clipboard API is a Windows DOS box specific thing, perhaps the clipboard API should be OFF by default and you should have to enable it in dosbox.conf to use it? And then, having the API off by default, maybe the blacklist would become unnecessary and could be removed entirely?
Waitsnake
commented
2 weeks ago @Waitsnake I never thought about that! INT 2F AX=1700h corresponds to WINOLDAP clipboard functions.
So. that means you can get Norton Desktop to correctly show the font by adding:
[dos] dos clipboard api=false
I mean I found that out also yesterday after I found that code part that was causing ND trouble, since there was this clipboard_dosapi variable that I followed. But disabling dos clipboard api would also disable the DOSBox clipboard functions (clip_mouse_button) right? Even I if I have not understand fully how they work. ;)
Maybe Norton coded their DOS program to care whether the Windows 3.1 DOS VM had clipboard functions enabled or not because the custom charset wouldn't translate properly if copied to the clipboard?
I found this article here from Raymond Chen (saw him on YT in 'Dave's Garage') the programmer that worked on WINOLDAP for Windows 95.
If I understand him correct then WINOLDAP runs only in a virtual DOS machine under Windows 3.1 or 95 to translate all those DOS graphic calls to Windows graphic driver calls. So under a pure DOS session Int 2F/AX=1700h should return 1700h (not active) and within a virtual DOS machine it should return its version number (and be <> 1700 by doing so).
Or more likely, if the user used ND.EXE in a Windows DOS "box" and the user was using it windowed, rather than fullscreen, the custom font wouldn't appear properly because Windows uses it's own font to render text mode.
Exactly, I think Norton did check for WINOLDAP to know when it was running in virtual DOS machine (under 3.11 ot 95) where their fancy direct access to font ram for extra graphics effects would not work anyway and so they fall back to standard ASCII graphic set. But once they know they are under real DOS with nothing between them and the Font RAM then a pointer, then they 'showed off' what they can do. 🤣
Waitsnake
commented
2 weeks ago This brings up an interesting question: Would it be possible to implement the clipboard API in a way that doesn't make DOS programs think they're running under Windows?
I'm don't know since I have no idea how this clipboard API is implemented and how it works in detail. And if there are other ways to do it. I only struggled with its side effects so far. 😅
Or, since the clipboard API is a Windows DOS box specific thing, perhaps the clipboard API should be OFF by default and you should have to enable it in dosbox.conf to use it? And then, having the API off by default, maybe the blacklist would become unnecessary and could be removed entirely?
At least for me it sounds like for sake of better compatibility with DOS programs clipboard API should be disabled by default. I mean who, except maybe Raymond Chen, would think that an active clipboard functions can cause incompatibility of how a DOS program looks like? I certainly not. 😅 I looked for days in all kinds of options in config file regarding graphics, looked at character sets, debugged the video bios interrupt functions and then the DOS interrupt functions. It was pure luck and curiosity that I wanted to find out what the "DOS Multiplex Interrupt" does (bc ND did many INT 21,35 - Get Interrupt Vector call and one of those was for 0x2F). A setting like "dos clipboard api=false" would have been the last thing I tried before.
Describe the bug
Custom characters for window elements and graphical mouse of Norton Desktop 1.0 for DOS (or just ND) for DOS is not working on dosbox-x (2024.03.01). E.g. instead of the graphical mouse cursor that ND uses in 'DOSBox 0.74 SVN' in dosbox-x only a yellow text cursor is used. And special elements like top left window close buttons, folder icons or the windows scroll elements look different when ND runs in 'DOSBox 0.74 SVN' and dosbox-x.
Steps to reproduce the behaviour
Expected behavior
I expect ND has graphical mouse cursor and no text block cursor and many special GUI elements like top left window close buttons, folder icons or the windows scroll elements use their own custom character set instead of standard Ascii characters.
What operating system(s) this bug have occurred on?
MacOS Sonoma 14.4.1 (23E224)
What version(s) of DOSBox-X have this bug?
2024.03.01 and 2023.10.06
Used configuration
Output log
No response
Additional information
Issue with dosbox-x (2024.03.01)
working fine with DOSBox 0.74.3.3 SVN
Have you checked that no similar bug report(s) exist?
Code of Conduct & Contributing Guidelines