Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
Ninho

E-mail

04.08.2016, 16:43
(edited by Ninho, 04.08.2016, 19:10)
 

WheelK : at last, use that mouse =wheel= in DOS ! (Announce)

Post reply

Hi !

I have written a tiny mouse driver extension, allowing you to take fuller advantage of that mouse wheel under DOS, at last : all it does is convert wheel ticks into "up" & "down" arrows (simulated grey key presses stuffed into the BIOS keyboard buffer), allowing one to use the wheel in programmes which are not designed to use it, or to use a mouse altogether.

WheelK can be used standalone, or as a complement to other programmes or mouse driver extensions, such as Bret Johnson's MousKeys, that process mouse events but are unaware of the wheel. WheelK will therefore process the wheel events itself and politely pass all other mouse events (button actions, movements...) to the "mouse user procedure" that was in effect before its loading, if any.

WheelK can be disabled/reenabled at will before executing a programme, or even from within a programme (that allows a user to "shell out" to DOS). It can be unloaded from the memory altogether if necessary. See instructions.

WheelK version 1 (demo) is here for your testing pleasure : the homepage of WheelK

Instructions for use are to be found on the webpage, and also in the "readme" included in the downloadable .zip

Prerequisites : 80286+ AT/PS2 compatible, mouse with a wheel (obviously), PC/MSDOS 2+ or compatible, CTMouse 2+ mouse driver (that provides the wheel API.); optional : Mouskeys.

Note this is intended to work on real hardware running a compatible DOS ! Virtual machines, emulations, including the "DOS box" under Windows, etc, may or may not provide adequate support for a wheel mouse. For similar reasons, WheelK may or may not work with a USB-mouse instead of a regular PS2-mouse. Actually it is the mouse driver, CTMouse, that may - or may not - detect and process a wheel under such emulations, and only if it does, WheelK should work as well.

(Edit:) Just tried in the VMware "player" running FreeDOS, CTMouse /O v2.1 recognised the wheel and WheelK worked perfectly. Wow ! So K00L ! Yet I advise testing/using this on real "iron"...(Edit ends)


I'm ready and eager to examine all reactions and suggestions for possible changes and imrovements, while a definite goal is to keep this minimalistic : WheelK's active resident code is only 32 bytes (currently using 96 bytes because I didn't employ the ultimate loading scheme).

One smallish addition I might make if the feedback is positive would be to process mouse button clicks, absent Mouskeys, so as to provide (fixed) translations to "Enter" and "Rscape".

Source code not bundled ATM - interested developers are welcome to request it by email.


@Rr : would you be interested in hosting WheelK on this, Bttr.de, site ?

@Bret : I gave your forum priority for the annoucement, expecting a few reactions from users of Mouskeys. However seeing it has received some 6 views...and no reply in 4 days, I'm bringing the subj to Bttr now. Furthermore while WheelK makes a logical complement for Mouskeys - and has been devised with it in mind - I believe it can also be useful by itself...

---
Ninho
RayeR

Homepage

CZ,
05.08.2016, 18:29

@ Ninho
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

And what happen if WheelK is loaded and you run a program like Arachne that handle wheel itself? Need to unload 1st?

---
DOS gives me freedom to unlimited HW access.
Ninho

E-mail

05.08.2016, 18:46
(edited by Ninho, 05.08.2016, 19:19)

@ RayeR
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

> And what happen if WheelK is loaded and you run a program like Arachne that
> handle wheel itself? Need to unload 1st?
Of course not. Only disable WheelK before running Arachne (also disable Bret's Mousekeys if using that too...). Reenable after exiting Arachne.
(Edit:) Explicitly disabling WheelK (resp. Mouskeys) definitely answers your concern, being probably overkill though - as when Arachne switches on its own "mouse callback" it would automagically zap WheelK's (respectively, Mouskeys') ones/
OTOH it /will/ be necessary to reactivate (Mousekeys and) WheelK (in that order) /after/ exiting Arachne, since the latter (most prbably) does not save the previous callback address : almost no program does (except WheelK !)
(Edit ends.)

The "readme" says it all - admittedly could be better written... Basicly though it's rather simple and nice, and it "just works"; the WheelK command line has three possible options :

- WHEELK E ; (Re)enabling the wheel. Also for initial loading.
The "E" is optional, WHEELK by itself is a simpler synonym...

- WHEELK D : Disabling the wheel, keeps WheelK in mem. Also continues to pass non-wheel mouse events to the previously installed mouse hook, if any (maybe MousKeys)

- WHEELK U : unloads, uninstalls, removes WheelK from the memory.

---
Ninho
RayeR

Homepage

CZ,
06.08.2016, 21:58

@ Ninho
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

I tried it but it doesn't work for me (MS intelli mouse exploerer 3.0 via PS/2). E.g. in file manager or links wheel does nothing. But in native wheel programs like Arachne, MPXplay, Quake2dos wheel works fine.

---
DOS gives me freedom to unlimited HW access.
Ninho

E-mail

07.08.2016, 00:19

@ RayeR
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

> I tried it but it doesn't work for me (MS intelli mouse exploerer 3.0 via
> PS/2). E.g. in file manager or links wheel does nothing. But in native
> wheel programs like Arachne, MPXplay, Quake2dos wheel works fine.
Please qualify "doesn't work". Does WheelK load itself OK or does its loading fail ? Please report what it prints while trying to load.

Just to be sure, is your CTMouse version current (2.0 or 2.1b4) ? If 2.1, you MUST give it option "/O", with 2.0 it was the opposite (/O meant no wheel !).

Assuming WheelK loads OK after CTMouse, it could be something with your DOS configuration is interfering, or the specific programs you have tried could be incompatible with the BIOS-buffer stuffing method used by WheelK to simulate key presses. I do not have links nor the 'which?) file manager.

Could you try a few more programs so we can narrow the problem ? Programs I am sure "just work" with WheelK for having tried myself : 4DOS (wheel scrolls thru command history), idem DosKey under MSDOS command.com . Buerg's "list". Dos port of Lynx 2.8.5...

Don't hesitate to (re)enable WheelK after running "mouse conscious" programs, for instance, as noted above the wheel works at the 4DOS command line (for me), but if you type F1 to get 4DOS help, that installs its own mouse hook which disables WheelK's - you must reenable WheelK after exiting 4DOS's help. And pretty much so after running any programme which has native mouse processing (wheel or no wheel).

If decidely WheelK won't work for you, we'd have to scan and review possible configuration issues both software and hardware in detail.

---
Ninho
RayeR

Homepage

CZ,
07.08.2016, 02:54

@ Ninho
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

I use CTMouse 2.1b4 under MSDOS 6.22 and of course with /O (as it works in other programs).
WheelK loaded successfully. I tried with links, volkov commander, DN and I use cmdedit for command history. But none of them responded to wheel movements as it would do if I press an arrow key.

---
DOS gives me freedom to unlimited HW access.
Ninho

E-mail

07.08.2016, 09:46
(edited by Ninho, 07.08.2016, 12:30)

@ RayeR
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

> I use CTMouse 2.1b4 under MSDOS 6.22 and of course with /O (as it works in
> other programs).
> WheelK loaded successfully. I tried with links, volkov commander, DN and I
> use cmdedit for command history. But none of them responded to wheel
> movements as it would do if I press an arrow key.
OK, thanks ! this narrows the enigma. WheelK loaded and enabled but not reacting to wheel actions suggests a possible cause, in relation with the BIOS, we must rule out first of all. WheelK demo uses the AT-BIOS service : int16 AH=5, to stuff keycodes into the BIOS keyboard buffer. This demo ( a more pompous word prototype might describe it better ) assumes the service will be present once it's checked it is running on a 80286 or higher. Is your machine "unusual", maybe very old (a genuine IBM PCAT from 1984 ?), or very new (uEFI machines are known to have oftentimes flaky and incomplete BIOS emulation) ? Can you assert whether it has an (working) int 16/05 service ? Can you try WheelK on a different machine ?

In the event the absence of the BIOS int is the problem, I \\\could make\\\\ (EDIT) have made a WheelK special for you, which does the buffer stuffing "by hand" instead of using the AT-BIOS.

The file's URL is : ninho(DOT)users(DOT)micso(DOT)fr/wheelk/WHEELK_S(DOT)COM
(not made it a clickable link in order to avoid unnecessary dissemination).
File WHEELK_S size 882 bytes, resident size a bloated 144 bytes ;=)

Please try it on that reluctant machine of yours, let's see if that was your problem...

---
Ninho
bretjohn

Homepage E-mail

Rio Rancho, NM,
07.08.2016, 16:31

@ Ninho
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

Just as an FYI, I've never used function 16.05 in my programs -- I've also stuffed the keyboard buffer "by hand", as you put it. That way it always works, whether the BIOS supports the function or not. But, it uses more memory that way. I can send you some sample code if you want.

You could also test function 16.05 to make sure it works as you're loading the TSR and display an appropriate error message.
Ninho

E-mail

07.08.2016, 17:18

@ bretjohn
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

Hi !

> Just as an FYI, I've never used function 16.05 in my programs -- I've also
> stuffed the keyboard buffer "by hand", as you put it.

I'm not surprised, I would've bet this is how your programmes did it, at least where necessary - be it only because your targets include (pre)historic PC/XTs, while I have limited myself to 80286-AT compatibles. Please realise WheelK at this point is just a minimalist proof of concept awaiting for comments, suggestions, & I've been fully aware of missing tests, including the one(s) for the presence of "16/05". Actually I made the WheelK, in part, to motivate /you/, after you told me on your forum that you have lost the original source code for Mouskeys, unfortunately, and that other priorities prevented you from resuming the work on it !

It would of course be much cleaner to have the wheel processing integrated in a revised Mouskeys, all-in-one, especially considering the flakyness of Microsoft-defined "mouse user procedure" :=)

> That way it always
> works, whether the BIOS supports the function or not. But, it uses more
> memory that way. I can send you some sample code if you want.
Thanks, I don't need that sample - I wrote my own on the fly in approx 5 minutes, it is included in the special modified WheelK (advertised in my previous reply for Rayer to test.)

> You could also test function 16.05 to make sure it works as you're loading
> the TSR and display an appropriate error message.
Of course, I should've added this particular test and/or the alternate "manual" way... while I want to avoid bloat & feature-creep, there are several modifications and possible enhancements I have marked as TODO or TODO? :=)

---
Ninho
RayeR

Homepage

CZ,
08.08.2016, 14:52
(edited by RayeR, 08.08.2016, 22:12)

@ Ninho
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

Hi, I did a quick test of WHEELK_S and it works. My current MB is Gigabyte GA-P67-DS3-B3 with old-style Phoenix/Award PnP Dual BIOS 6.00PG - not UEFI yet. I found that some programs like to nuke the wheelk - links, VC, DN. Under VC and DN filemanagers I cannot make it working even when reload wheelk after start up of the program. It says "updated" but wheel don't work. In micromanager od cmdedit command line it works normally. Links nuke it at startup but when I run DOS shell, reenable wheel and go back to links then it stays working. I must retest original wheelk - maybe I nuked it with these programs and I don't remember if I tested it after reboot on cmdedit.

UPDATE: Sorry for the confusion but original wheelk works same as WHEELK_S but both was nuked by VC, DN and links. So there's any problem with BIOS but it is good idea to check for the BIOS function if present on load :) Would it be possible to make wheelk more permanent?

---
DOS gives me freedom to unlimited HW access.
Ninho

E-mail

09.08.2016, 00:51

@ RayeR
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

> UPDATE: Sorry for the confusion but original wheelk works same as WHEELK_S
> but both was nuked by VC, DN and links. So there's any problem with BIOS
Thanks God !

> but it is good idea to check for the BIOS function if present on load :)
The demo does test that 1. CPU >= 80286, 2. the BIOS "model byte" was <= 0xFC.
While this is not precisely targeting the int 16 service, yet it should ensure the machine was AT/PS2/"industry standard" compatible... It should cover 99 % of the base, which is why I was worried with your earlier report. All's well that ends well...
Yes, I'll add some other check, while keeping in mind it has to work on widely different systems and BIOSes (and bugs too) in the field... Also any test must stay compatible with virtual mode memory managers ala EMM386.

> Would it be possible to make wheelk more permanent?
It's difficult, considering the way CTMouse, WheelK and the foreground programs interact. I guess a user has to learn how to cope with his programs by trial and error.

> My current MB is Gigabyte
> GA-P67-DS3-B3 with old-style Phoenix/Award PnP Dual BIOS 6.00PG - not UEFI
> yet. I found that some programs like to nuke the wheelk - links, VC, DN.
> Under VC and DN filemanagers I cannot make it working even when reload
> wheelk after start up of the program. It says "updated" but wheel don't
> work.

I have a few changes and things in my bag of tricks to try, that may fix certain cases.

However any program that short-circuits the BIOS buffer altogether and instead expects to get keys after keyboard interrupts will not work with the current 'stuffing' method employed by WK. Though I've "been there done that" more than once with the grey art of forcing scan codes thru, and interruptz from, the 8042-alike keyboard controller (aka Bret's "/K" method) I am very reluctant of bloating my tiny puppy with that kind of cuisine, besides being a can of worms, compatibility-wise : keyboard controllers in the real world vary wildly...

> In micromanager od cmdedit command line it works normally. Links nuke
> it at startup but when I run DOS shell, reenable wheel and go back to links
> then it stays working.
You have certainly played with WheelK more thoroughly than I !
Thank you very much for testing it, and reporting your findings !

---
Ninho
bretjohn

Homepage E-mail

Rio Rancho, NM,
09.08.2016, 21:02

@ Ninho
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

> The demo does test that 1. CPU >= 80286, 2. the BIOS "model byte" was <=
> 0xFC.
In addition to doing that, you can also check that it really works (actually simulate a keystroke and see if it appears in the keyboard buffer or not).

> However any program that short-circuits the BIOS buffer altogether and
> instead expects to get keys after keyboard interrupts will not work with
> the current 'stuffing' method employed by WK. Though I've "been there done
> that" more than once with the grey art of forcing scan codes thru, and
> interruptz from, the 8042-alike keyboard controller (aka Bret's "/K"
> method) I am very reluctant of bloating my tiny puppy with that kind of
> cuisine, besides being a can of worms, compatibility-wise : keyboard
> controllers in the real world vary wildly...
My USBKEYB program includes an external API for simulating keystrokes with the /K method. You can check for that API, and if it exists, use it to simulate the keystrokes via scan codes so you don't have to do it yourself. Indeed it is a can of worms, but a necessary one to open if there is any hope of creating a usable DOS USB keyboard driver.

Also as an FYI, the next version of USBMOUSE will include a similar API to simulate/virtualize mouse movements and button presses.
Ninho

E-mail

09.08.2016, 23:38

@ bretjohn
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

> > The demo does test that 1. CPU >= 80286, 2. the BIOS "model byte" was <=
> > 0xFC.
> In addition to doing that, you can also check that it really works
> (actually simulate a keystroke and see if it appears in the keyboard buffer
> or not).
Yeah, but... I'm not sure it is 100% correct, depending on the BIOS int 16/05 which might "STI" before returning, thereby allowing other processes to consume the injected key before we had a chance to check it reached the buffer. Possibly not a serious objection in practce, but needs more analysis and, frankly, the tests above should leave very few false positives while being perfectly safe.

Actually; ICBW but I think the only outliers must be very early revisions of the orignal, IBM brand, PC-AT. For those, identification of the BIOS by date and/or examination of the feature byte (int 15/C0, which is safe to call) and correlating with Ralf's interrupt list would be a good determination - and overkill too... such machines must rest in a tehnological museum.

...

> My USBKEYB program includes an external API for simulating keystrokes with
> the /K method. You can check for that API, and if it exists, use it to
> simulate the keystrokes via scan codes so you don't have to do it yourself.
> Indeed it is a can of worms, but a necessary one to open if there is any
> hope of creating a usable DOS USB keyboard driver.

> Also as an FYI, the next version of USBMOUSE will include a similar API to
> simulate/virtualize mouse movements and button presses.
Yeah but... it's Mouskeys we'd wish to have such a callable API !

---
Ninho
bretjohn

Homepage E-mail

Rio Rancho, NM,
10.08.2016, 17:44

@ Ninho
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

> Yeah, but... I'm not sure it is 100% correct, depending on the BIOS int
> 16/05 which might "STI" before returning, thereby allowing other processes
> to consume the injected key before we had a chance to check it reached the
> buffer. Possibly not a serious objection in practce, but needs more
> analysis and, frankly, the tests above should leave very few false
> positives while being perfectly safe.
Actually, testing to see that it does what it's supposed to do is the only legitimate test there is. If your program running in the foreground (while it is installing) doesn't see anything appear in the keyboard buffer then no other program will see it either. This is true no matter what's causing the problem (a broken BIOS or a TSR that's intercepting things or some other problem). And, if it doesn't work, you shouldn't try to install yourself.
Ninho

E-mail

10.08.2016, 18:45

@ bretjohn
 

WheelK : at last, use that mouse =wheel= in DOS !

Post reply

>> Yeah, but... I'm not sure it is 100% correct, depending on the BIOS int
>> 16/05 which might "STI" before returning,

> Actually, testing to see that it does what it's supposed to do is the only
> legitimate test there is. If your program running in the foreground (while
> it is installing) doesn't see anything appear in the keyboard buffer then
> no other program will see it either. This is true no matter what's causing
> the problem (a broken BIOS or a TSR that's intercepting things or some
> other problem). And, if it doesn't work, you shouldn't try to install
> yourself.
If int 16 makes itself interruptible again after after it has finished stuffing the key but before IRETing, it might be, for instance, interrupted by
a legitimate IRQ from the KbC - which would cause us difficulties. And I am not even considering here the case with DOS multitaskers. Anyway, I'll decide make my mind when I come back to WheelK in a few days. These preinstal checks do not represent a big deal, the worst that can happen is for WheelK to stay resident but have no effect, so what ? Let the affected user say : oh! the darned thing not worka here! ... and if he chimes in and provides a meaningful report, we might look at it.

I prefer to spend some time deciding whether to provide more options than just E/D/U, but without confusing the user. And what the defaults should be, for instance when unloading WheelK, should we restore the MUP as we found it while loading (this is what WheelK is doing currently), or Zero it (like all other programs do). Which way will provide the better and more intuitive user experience ? Need to experiment.

After all I'm doing this for my own use, and I'm happy to polish it /slightly/ more in order to give something which some in the waning DOS community can find useful. I'm certainly not going to turn myself into a self-made slave chasing the impossible :=)

And thank you, Bret, for your observations .

---
Ninho
Wengier

E-mail

14.08.2016, 02:56

@ Ninho
 

Mouse wheel is now supported in vDos-lfn too

Post reply

Thanks for the software. I, the developer of vDos-lfn and DOSBox SVN-lfn, also added mouse wheel support to vDos-lfn. Now vDos-lfn will automatically convert mouse wheel movements into up & down arrows just like WheelK. This feature is now enabled automatically, and there is no CTMOUSE required.

P.S. For those who don't know, vDos-lfn is a general-purpose non-gaming DOS emulator based on vDos, but with many additional features such as long filename and enhanced keyboard & display support. And vDos-lfn is being actively maintained. The installer for vDos is available from:
http://individual.utoronto.ca/wengier/vdos-lfn-setup.exe

And the latest portable ZIP package of vDos-lfn is available from:
http://individual.utoronto.ca/wengier/vdos-lfn.zip

Wengier
bretjohn

Homepage E-mail

Rio Rancho, NM,
14.08.2016, 17:55

@ Wengier
 

Mouse wheel is now supported in vDos-lfn too

Post reply

One feature I would like to see everywhere the wheel is supported in a "generic" (non-program-specific) fashion is to have the typed keys be configurable. For example, instead of single arrow keys, do multiple arrow keys, PgUp/PgDn, "scrolling" arrow keys (temporarily enable ScrollLock while pressing the arrow keys), pressing Control-Arrow key combinations, etc.
Wengier

E-mail

14.08.2016, 20:41

@ bretjohn
 

Mouse wheel is now supported in vDos-lfn too

Post reply

> One feature I would like to see everywhere the wheel is supported in a
> "generic" (non-program-specific) fashion is to have the typed keys be
> configurable. For example, instead of single arrow keys, do multiple arrow
> keys, PgUp/PgDn, "scrolling" arrow keys (temporarily enable ScrollLock
> while pressing the arrow keys), pressing Control-Arrow key combinations,
> etc.
Thanks for the suggestion! I have added the WHEELMOD option to the vDos-lfn config file to make the mouse wheel feature more customizable. Maybe I will add even more customization to it soon.

Wengier
RayeR

Homepage

CZ,
16.08.2016, 17:54

@ bretjohn
 

Mouse wheel is now supported in vDos-lfn too

Post reply

> One feature I would like to see everywhere the wheel is supported in a
> "generic" (non-program-specific) fashion is to have the typed keys be
> configurable.
It would help for links too as I can see the pressing of down key moves to next link instead of scroll... But it would be better to implement wheel support directly in links source as it was done in Quake2DOS...

---
DOS gives me freedom to unlimited HW access.
Back to index page
Thread view  Board view
22777 Postings in 2122 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum