Re: [Freedos-user] FreeDos in VirtualBox not a sure thing

2012-08-17 Thread Dave Pratt
John,

I'll let Mike and others respond about the details of MS-Client - you should 
note, however, that MS-Client is not FreeDOS software - it is Microsoft 
software.

If I understand you correctly you are using networking only for the purpose of 
accessing a printer on the host computer.

If this is true I would recommend using VMWare player and creating an LPT port 
for your DOS application to use. (I don't think that this can be done in 
VirtualBox)  Then on the host Windows machine use NET USE or some other sort of 
mapping technique to map LPT1 to the appropriate network printer.  

Of course you will then get the usual problems with running a new printer with 
old DOS programs. Do you have a DOS compatible printer?

If all you are doing with networking is printing on your local PC, I would get 
rid of MS Client as well as the power management utitlities and see how your 
application works.

For accessing drives I would again use VMWare and the excellent VMSMOUNT.EXE 
program which will allow your DOS system to access any directory on the Windows 
host - again without using networking software in DOS.

Dave



-Original Message-
From: john s wolter johnswol...@wolterworks.com
To: Michael B. Brutman mbbrut...@brutman.com
Cc: Discussion and general questions about FreeDOS. 
freedos-user@lists.sourceforge.net
Sent: Thu, Aug 16, 2012 9:05 pm
Subject: Re: [Freedos-user] FreeDos in VirtualBox not a sure thing


Mike,


Good to make your acquaintance.   Let me respond to your questions and remarks 
below.


On Thu, Aug 16, 2012 at 12:23 AM, Michael B. Brutman mbbrut...@brutman.com 
wrote:


John,

Maybe you could help us by being very specific with what worked and what went 
wrong?  The only thing I could gather from your message was that it was 
difficult to do, and it was slow.



I took a moment to get a specific speed measure.  It is an extended ASC-II set 
display application.  Inside the VM I run an application batch file which among 
other items like NET USEng a printer loads DEVLOADs NANSI.SYS.  


Since the initial display is going at a slow rate I used a stopwatch to 
estimate the time to display the first 40 characters.  They are the upper 
border line using 40 characters ' * '  .  It took 4.7 seconds for those 40 
characters to be displayed.  That is 8.5 characters per second written to the 
screen.  That screen has a simple one column bar-menu that uses the up-down 
arrows.  Each entry of a up or down arrow has a lag to it.


I rate that as slow.
 
One thing that is essential for good performance is to ensure that your host 
machine is new enough to support the virtual processor extensions in the CPU.  
If it does not, then the virtual machine gets emulated one instruction at a 
time.  This is orders of magnitude slower than if you can use the virtual 
processor extensions.  My 3 year old Intel i5 Quad Core chip is fine, but 
modern Atom processors do not have the extensions.  Any virtual machine 
(FreeDOS or otherwise) will be painful without them.  It sounds like your 
machine has the processor extensions, but you need to ensure they are enabled 
in the BIOS.



Both the development and target are i5 Laptops with 6-8 GB RAMM.  Those are the 
most important performance spec.


The VT features are turned on.  I have turned it off without any noticeable 
difference in performance.
 

Even if you do not use the power saving TSRs or programs that are power aware, 
the worst that will happen is that the virtual machine running FreeDOS will use 
one of the host CPU cores.  For a desktop system this is not a major problem.  
On a laptop it will shorten battery life.  You have a wide variety of TSRs to 
choose from - FDAPM and DOSIDLE are my favorites so far.



I'm using the power saving FDAPM and APMDOS..  Why are the power saving 
utilities are playing a role is a question? 


FreeDOS's NANSI.SYS is used as it is required to see anything on the display.  
SHARE is being loaded.



CIFS/SMB issues:


...Loading...
PROTOCOL.INI
SHARE
netbind
tcptsr
tinyrfc
nmtsr
emsbfr


NET CONFIG gives the default freeDOS computer and user information.  The NET 
VIEW gives the host but will not give information for the host attached 
printer.  I am able to NET USE LPT1: \\... to assign it.  I had altered the 
workgroup to the host's local workgroup.  NT or Acitve Directory Domains are 
NOT used.  Simple workgroup networking is active.


It keeps asking for an ID and password for the printer.  I provide the same as 
I do signing on to the computer itself.  I have not yet seen a way to 
administer passwords for the directories or printers shared by the host.  It 
seems to get the ID but tells me the password does not match the printer's 
password.  Microsoft has done a great job of obscuring things.


One point of confusion is the setup of mTCP vs MS-Client.  It is not clear how 
independent these are of each other.  Can one have a static IP while the other 
gets a dynamic, DHCP?  


I have just found the 

Re: [Freedos-user] FreeDos in VirtualBox not a sure thing

2012-08-17 Thread Michael B. Brutman

John,

Just to make sure I understand ...

You are running a batch file that is doing net use to setup printer 
shares, a file share, and loads nansi.sys.  And the output to the screen 
during that time is around 8.5 chars per second?

Just as a comparison, running the FreeDOS Beta of 1.1 under VirtualBox I 
can go to c:\fdos\doc\mtcp and execute type ftpsrv.txt.  The entire 
time to watch that 37KB file scroll by is around 7 seconds, or about 
5200 chars per second including the scrolling time.  (The time to scroll 
is longer than the time to print chars.)

Is VirtualBox slow because of what you are doing in those batch files, 
or is it slow no matter what you do?  For example, try my little test 
there and see how fast it goes.  We need to isolate what is causing your 
slowdown.  And please try this with both TSRs and device drivers loaded 
and without so that we can see if it is a TSR or device driver problem.

I have never heard of something that slow before in VirtualBox. As an 
alternative, you can try VMWare to see if it is something specific to 
VirtualBox.  (I have found problems in VirtualBox before related to 
programs that reprogram the programmable interrupt timer.  The mTCP PING 
program exposed it.  It only affected PING while it was running.)

RAM should not be the issue.  But laptop hardware tends to throttle the 
speed if it is not plugged into the wall and allowed to run at full 
speed.  I doubt this is your problem, but just in case, please clarify 
that the laptops are on wall power and are set to run at maximum CPU 
speed while on wall power.

FDAPM and APMDOS are only introduced as a way to conserve battery power 
or reduce electricity consumption when used with wall power.  Which 
reduces heat, which is always a good thing ...

mTCP requires its own network adapter and can not co-exist with 
MS-Client.  The same is true for WATTCP based applications.  If you are 
trying to use both the MS-Client and mTCP or WATTCP programs at the same 
time on the same adapter then you need to add another adapter.  Each of 
those programs assumes that they own the adapter and will fight each 
other in fun ways.


Mike



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] FreeDos in VirtualBox not a sure thing

2012-08-17 Thread Eric Auer

Hi! Two thoughts about NANSI being slow in VirtualBox
while network drives and printers are used and FDAPM
is active: In DOSEMU, you can configure how agressive
screen updates should be. So it can try to keep up
with screen updates, or it can just occasionally do
a window update. DOSEMU also runs DOS in a window in
Linux, so it is similar to a VM, but differs in not
emulating the CPU. It just emulates keyboard, screen
and similar hardware for DOS :-) If you tell DOSEMU
to only update the window 10 or 20 times per second,
you get a nice user experience at little CPU load.

The second thought is that network printers / drives
combined with your other software (NANSI probably is
no interesting factor here, but you can try NNANSi,
or try other command line options for NANSI first?)
and FDAPM might get FDAPM to try to save too much of
your CPU load, so you save a lot of energy but get a
sluggish, unpleasand user experience. Read the FDAPM
documentation for alternative command line options,
e.g. the ADV: style ones, to make it more cautious.

Note that not loading any FDAPM style software can
be another option, but depending on your VM, could
lead to permanently high CPU load. You can try to
use other software like DOSIDLE or try the FreeDOS
kernel (config.sys) IDLEHALT option, which acts a
bit like a FDAPM lite, saving energy mostly when
waiting for keyboard input only :-) Sometimes the
VM itself also has options to save energy or limit
the amount of CPU time available to DOS. In plain
real hardware, FDAPM SPEED options can be used to
activate ACPI throttle. That freezes your CPU for
each N out of 8 time slices (of e.g. 1/32000 sec).
While being much less elegant than modern ways to
lower the complete CPU clock and voltage, it gives
at least SOME way to forcibly limit CPU usage :-)
Note that low speeds below 4 can feel jerkish...

Regards, Eric








--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user