Dear All,

 

The new vDos solution is very promising indeed!

Only when I print all my printer codes are in the text!

Am I doing something wrong?

 

Jan Hartman

 

Van: [email protected]
[mailto:[email protected]] Namens Schaars (Jos)
Verzonden: dinsdag 24 december 2013 13:11
Aan: [email protected]
Onderwerp: [Dataperf] vDos

 

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

Reply via email to