DOS ain't dead

https://github.com/DosWorld/clipdrv/

Clipboard driver and command-line tool.

1. Driver for clean DOS (and DosBox). Provide win-clipboard API (INT 2Fh, AX=1700h...170Ah) and allow copy to clipboard a text-mode screen with <PrintScreen> key. In graph mode - pass call to prev INT 5 handler. From now, no more reasons to skip support clipboard in new software.

2. Command-line tool allow do copy/paste between clipboard and stdin/stdout. Handle direct input and redirection. For direct input support ^Z or ^D as EOF marker.

Clipboard size is 64k-limited (placed into XMS).

MIT License

https://github.com/DosWorld/lbforth

Public-domain forth in C by Leif Bruder, ~1k loc (easy reading, imho). I am does not see this forth in other places, imho, need pay attention.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> Clipboard driver and command-line tool.
>
> 1. Driver for clean DOS (and DosBox). Provide win-clipboard API (INT 2Fh,
> AX=1700h...170Ah) and allow copy to clipboard a text-mode screen with
> <PrintScreen> key. In graph mode - pass call to prev INT 5 handler. From
> now, no more reasons to skip support clipboard in new software.
>
> 2. Command-line tool allow do copy/paste between clipboard and
> stdin/stdout. Correct handle direct input and redirection. For direct input
> support ^Z or ^D as EOF marker.
>
> Clipboard size is 64k-limited (placed into XMS).

Cool! However, since you don't provide binaries, perhaps you should put in a few words about the tools that are used for that?

---
MS-DOS forever!

> Cool! However, since you don't provide binaries, perhaps you should put in
> a few words about the tools that are used for that?

There's a giant BIN/ subdir, but I guess you mean under Releases.

> There's a giant BIN/ subdir, but I guess you mean under Releases.

Yes, just looked in "Releases". The binaries are in BIN and the tools used are, I suppose - in TOOLS. Probably it would be somewhat easier to handle if these things are supplied in a zipped binary in RELEASE-20241115, Assets.

---
MS-DOS forever!

> Yes, just looked in "Releases".

Sorry, I am just make release as tag for git and don’t think/care about created .zip
I'll try to fix it tonight,

In git master branch:
BIN - contains clipdrv.exe and clipcli.com
TOOLS - contains Sphinx C— compiler (minimal version) required for compiling only.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> Sorry, I am just make release as tag for git and don’t think/care about
> created .zip
> I'll try to fix it tonight,

No hurry - it's a rather minor issue.

> TOOLS - contains Sphinx C— compiler (minimal version) required for compiling only.

Somewhat more serious: if I try to launch C--.exe, the machine just reboots ( using MS-DOS 7.1 ).

---
MS-DOS forever!

> Somewhat more serious: if I try to launch C--.exe, the machine just reboots
> ( using MS-DOS 7.1 ).

I’ll check my env. Sphinx never was stable compiler - die with exception (instead error message) - it’s ok, for c—.
HP t5740 thin client, 8gb ram, himemsx (latest), Freedos 1.3

PS: I am a little bit optimize code - each wasted 100 bytes of tsr-code can be painful for user.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> if I try to launch C--.exe, the machine just reboots

c-- can goes mad if some startup files is missed. i am check it (remove c-- from path and C-- env var), files is enough. :(
I have no other ideas. May be problem into zrdx? (extender used in c--)

You can download binaries from this page.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> > if I try to launch C--.exe, the machine just reboots
>
> c-- can goes mad if some startup files is missed. i am check it (remove c--
> from path and C-- env var), files is enough. :(
> I have no other ideas. May be problem into zrdx? (extender used in c--)

In DosEmu2 C--.exe did run fine. That made me try:

C:\>hdpmi32 -r -x
C:\>jemmex novcpi
C:\>c--

and the compiler runs without rebooting under MS-DOS 7.1.

So the problem is: the DOS extender used in C--.exe is 1) unstable and 2) doesn't use an external DPMI host if VCPI is available.

---
MS-DOS forever!

i am update clipdrv. (and link in my prev post)

PS: Not think so, if you need - https://github.com/DosWorld/zrdx/ (source code collected from webarchive). You work more close with dpmi-hosts.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

> Clipboard driver and command-line tool.

2All: Also, if your project support clipboard and you try with clipdrv, let me known (link to project). I don't expect create full list of software (which use clipboard), but will be nice see situation.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.

It works in TDE, but not MouseClip (both on my site). The difference is TDE tests if open returns not 0 (having already determined that the clipboard is available), but MousClip tests 0x1701 (as a combined available/open test). ClipDRV should be returning 1 for open, but it is not (AX is simply not set). Similarly, version should be returning BX=1, but it doesn't (BX is popped).

> It works in TDE, but not MouseClip (both on my

Cool. Thanks! I'll check it (i am on vocation, till Dec 6, and is far from my PC). BX is popped - mistake. All others:

Regarding to MS documentation:

Name            IdentifyWinOldApVersion()
Parameters      AX = 1700H
Return Values   AX == 1700H: Clipboard functions not available
                  <> 1700H: AL = Major version number
                            AH = Minor version number
---
        IF(AX == CB_API_GETVER) { // 1700
                AX = CLIPDRV_SIGN;
                BX = CLIPDRV_VER;
---

Name            OpenClipboard()
Parameters      AX = 1701H
Return Values   AX == 0: Clipboard already open
                  <> 0: Clipboard opened
---
        } ELSE IF(AX == CB_API_OPEN) { // 1701
                AX = TRUE;
        }
---
(TRUE = -1 in c--, if i am not wrong)

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.


         } ELSE IF(AX == CB_API_OPEN) { // 1701
                 AX = TRUE;
         }

That's fine, the problem is that it's not actually present in the binary.

    cmp    ax, 1701h
    jne    <next_test>
    jmp    <exit>


A few of suggestions for ClipDrv:

* Allow use of EMS and regular memory instead of just XMS (this would allow use on an 8088 CPU, though might require decreasing the max clipboard size)
* Provide way(s) to mark just part of the screen for copying to the clipboard (w/ keyboard and/or mouse)
* Allow new contents to be appended to the end of the clipboard instead of just overwriting the existing contents
* Provide a way for contents of clipboard to be "typed" as output instead of just outputting to STDIN from the command-line (with mouse and/or keyboard)

I would actually like to see ClipDrv just be the clipboard itself using the WinOldAp API (with the added ability to append contents to the end of the clipboard) and see the PrintScreen capability as a separate program, or at least with the ability to disable the PrintScreen feature. That would allow for better interaction with other programs that might use the Clipboard and/or PrintScreen key.

> * Allow use of EMS

+

Also, may be, keep into tmp file (but looks complete insecure, if we can talk about security in context of DOS applications)

> I would actually like to see ClipDrv just be the clipboard itself using the
> WinOldAp API

Right now, i am implement features described into MS document (API+PrintScreen). Imho, it is minimal (and basic) implementation - "low-cost driver". All others - may be better create something like "clipboard-manager" - this features can make huge code, not everybody want it - so better separate it.

---
Make DOS great again!

Carthago delenda est, Ceterum censeo Carthaginem delendam esse.