Hi all,
Here Jos Schaars, responsible for the vDos program. As some of you, I first tried DOSbox to run DOS programs on Windows 64 bit. It didn’t do the job, even worse it messed up databases while using it in a multi-user setting. I felt challenged to improve DOSbox to make it more suitable for serious programs. Most of the gaming and hardware emulating stuff was thrown out first and more. Then a few additions and changes would be adequate, so I thought. I got tangled in the process to get something that worked as I required. Got it done and tested it with several DOS applications. Decided to make it public so there would be an alternative to using DOSbox or (a virtual) XP. I’m not familiar with DataPerfect, I never used it. Gerard van Loenhout showed me how and why he’s still using DP. And he convinced me DP still has its merits for an ancient program as it is. I’ll go into the issues Danny Meirte reported: Nice is the faster startup of the DosBox-like environment. The vDos window is even shown with an delay, so you won’t get that black empty DOS screen echoing autoexec commands, but mostly only your application. however the reaction time (due to filelocking?) seems much longer than in the VMware solution. Filelocking cannot be the reason for this. Probably it is due to vDos not caching any file operations, but directing them immediately to Windows. Caching was/is a major concern in DOSbox when used in a multi-user setting. Perhaps vDos could distinguish between shared and private files like the temp files of DP and cache the latter ones. And this could improve performance? we use a Belgian keyboard The public version of vDos still uses a hard linked US Internal keyboard layout. A few days ago I was confronted with this by another AZERTY keyboard user. J I made some changes so vDos will support nationalized keyboards. I still have some issues with this, for instance Gerard pointed out that the Shift keypad keys didn’t work in DP as expected. I’ll await comments from that other Belgian user. AND I need the CHCP instruction (in fact CHCP 851 using a special c_851.nls file with a customized DOS to Unicode mapping) : which parameters do I need in the config.txt and/or autoexec.txt ? For now you’re out of luck, the codepage is also hard linked to mostly 437. I was already looking on how to implement the codepage of the Windows system. I didn’t consider the use of a nls file, though it would be an option to let’s say use a vDos.nls if present in the startup directory. How to change the TTF used [I need Consolas or DejaVu Console although Lucida Console will do] Until some moment I had the TTF file external (vDos.ttf). I embedded it as I noticed that the SDL library was frequently reading that file and people were installing that font, assuming it was needed for vDos to work. I already regretted that, especially as a Hungarian (?) requested for some localized characters to display. I sent him an older version with the external file to modify, but this is not the way to go. Probably I’ll make it external again and load it at startup. But that won’t help you: the ASCII to Unicode translation is (still) hard linked. Furthermore the vDos TTF font is optimized for the fixed character cell dimensions 1:2, 8:16… in vDos. Consolas and others won’t look nice, especially with line drawing characters not connecting. The vDos font probably would have to be extended with the Unicode characters of the desired codepage. And I’m not that eager to do that, but if anyone is… By the way: in the TTF used by vDOS, the panellink-symbol, which is highly important in DP, (ASCII 176) is difficult to distinguish, and the codepage used lacks the euro-symbol. ??? ASCII 176 is a shaded block, ASCII 128 is used for the euro-symbol. You could put a REM before color = true in the config.txt, that would give you the original DOS colors with a bit more contrast. In the startup batch-file we can launch a keyboard enhancer… I’m unaware why someone would need a keyboard enhancer. Not just at the commandline/autoexec.txt, but DOS programs also can start Windows programs directly. vDos checks if the requested program is DOS or Windows before launching it. Perhaps the use of the latter is too crippled due to the path being DOS 8.3. If for instance vDos C; is set to Windows C:, the DOS program cannot reach something like C:\Program Files\... Perhaps I should make an exception for this. Why are all directories and files containing an underscore (ASCII 95) not accessible? By design all directories and file names have to confirm to the 8.3 DOS naming limitation to be visible in vDos. But names with an underscore (ASCII 95) are accepted as far I can tell. I hope you can add the ability to copy selected text from the screen by using the mouse [kind of QuickEdit mode]?... Sorry, I settled for Ctrl+C and Ctrl+V for copying and pasting text. Every Windows user probably knows at least these two key combinations. vDos consuming 100% of a processor core. In the past vDos needed a modest 0-5% by releasing at fixed intervals time back to the operating system. I could improve the performance by a 10-20% by making this more adaptive to the DOS program being busy or not. Never tested this with DP and indeed vDos doesn’t catch DP being idle. So I modified the scheme somewhat. Ending: I’m a bit handicapped with using the SDL libraries. DOSbox uses these to support more than just the Windows operating system. vDos inherited this, but I’m only interested in Windows and vDos only runs on this. I would gladly do without those SDL libraries, at some points in vDos I even have to correct some quirks of it. But it would take some time to rewrite the routines that rely on the SDL libraries. L vDos is maintained in spare time, so don’t expect too much too soon. happy holydays, Jos Schaars
_______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/cgi-bin/mailman/listinfo/dataperf
