Jos, welcome to the DataPrefect mailing list. I am very happy with vDos. My database(s) run 100% perfect under Win 7 and 8 - 64 bits. Even on my office network. Appr. 7 full time users.
I leave all vDos issues from now on to you. I can't be of much help there anyway. Merry X-mas to all of you! Gerard 2013/12/24 Schaars (Jos) <[email protected]> > 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 > >
_______________________________________________ Dataperf mailing list [email protected] http://lists.dataperfect.nl/cgi-bin/mailman/listinfo/dataperf
