Re: New vDos and vDos-lfn version 2016.06.01

  • From: "Wengier W" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "wengierwu" for DMARC)
  • To: "xywrite@xxxxxxxxxxxxx" <xywrite@xxxxxxxxxxxxx>
  • Date: Fri, 3 Jun 2016 03:19:03 +0000 (UTC)

Hi James and Carl,
Regarding LPT4=CLIP, the good thing I want to point out is that the opposite 
direction, "COPY LPT4 FILE" does indeed work in vDos(-lfn) 2016.06.01, which 
did not work in original vDos 2015.11.01 or earlier. vDos version 2016.06.01 
has this feature added, but unfortunately the earlier feature become broken as 
of now. Hopefully it will work both ways soon.
Wengier 

    On Thursday, June 2, 2016 9:45 PM, James Woolley <woolleyj@xxxxxxxxxxxxx> 
wrote:
 

 Carl, thanks for your comments about Wengier's new vDos-lfn. I think 
the LPT4=CLIP functionality is really essential--now that I have it, 
I wouldn't want to be without it. I very much appreciate the 
continued development of vDos and vDos-lfn by Jos and Wengier and am 
still hoping that this clipboard matter can be addressed.

James



At 2.6.16 00:44, you wrote:

Reply to note from "Wengier W" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted
sender "wengierwu" for DMARC) Thu, 2 Jun 2016 03:37:31 +0000 (UTC)

Jos has released the new vDos 2016.06.01 today, and I also
released vDos-lfn 2016.06.01 today accordingly.

Wengier, thank you. My very brief testing so far shows the following:

- Speed seems noticeably faster. Nice.

- Clipboard functionality appears to be broken. With LPT4=CLIP, saving
a file to LPT4 does not save it to the clipboard. Pasting with Winkey-
Ctrl-V also doesn't work: nothing happens.

- The new WAIT option for starting Windows programs doesn't seem to
work. For example, DOS /C METAPAD.EXE starts the Metapad text editor,
but DOS /C WAIT METAPAD.EXE does nothing. DOS /C HIDE METAPAD.EXE does
start Metapad in the background, as expected.

- I'm not sure what the new "CMD" command adds. In the previous version
of vDos-lfn, commanding CMD at the DOS prompt opens a CMD.EXE window in
Windows. There is no change in this behavior in the version, although
the CMD.EXE window does appear to open faster.

I realize that some or all of these comments might be better addressed
to Jos.

Thanks again for all your work.

--
Carl Distefano
cld@xxxxxxxxxx




   

Other related posts: