Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
Ninho

E-mail

12.06.2011, 15:51
(edited by Ninho, 12.06.2011, 17:05)
 

KBFR 1.9 last beta before release candidate (hopefully) (Announce)

Uploaded KBFR 1.9 (beta),
hopefully the last before release candidate 2.0. It's been ready for a week, unfortunately I'd had no time to pack and upload until today :(

What's in it to like ?

Users/ testers :
> KBFR by itself, or KBFR + : (loads, and) activates French keyboard translation
> KBFR 0 , or KBFR - : (loads,) deactivates.

There is no more a separate KBZERO build, load KBFR 0 instead.
Slash deprecated as option introducer.

> KBFR U , or KBFR D : removes from memory (or if impossible, because some int 15h TSR like SMARTDRV was loaded after it, disables)

Tester can switch between US English, French, and their previous keyboard driver if any (see ENGLISH.TXT)

Command now returns consistent errorlevel codes reflecting the current state : 0 = KBFR resident, Fr. translation active
1 = KBFR resident, inactive (kb BIOS, or previous kb driver, active)
2 = KBFR not in memory.

Developers :
Legacy int 2F based scheme is gone, a brand new int 15h method is used to communicate with an installed instance of KBFR. I've no time to explain the workings and rationale of said method now but will post a bit about it later and it can be discussed if anybody's interested (again, sorry. Meanwhile cf. included source.)

What's coming next ?

Auto-highloading will be reintroduced and defaulted to. Of course any bugs you report of observation you may make apropos this beta shall be given proper attention. Hopefully the next version can be called a release candidate and we will be very nearly done with this mini project...

As always *Please* help with comments, this call may include lurkers ;=)

---
Ninho

FFK

Homepage

12.06.2011, 23:58

@ Ninho
 

KBFR 1.9 last beta before release candidate (hopefully)

I tried it, and it works perfectly !
It takes only 496 bytes of low memory.
And finally it unload without any problem with the "u" switch.

Ninho

E-mail

13.06.2011, 12:36

@ FFK
 

KBFR 1.9 last beta before release candidate (hopefully)

> I tried it, and it works perfectly !
> It takes only 496 bytes of low memory.
> And finally it unload without any problem with the "u" switch.

Thank you for trying out!
Assuming your trial was run with a real French keyboard connected, did you like the feel of the CAPS Lock mode (as opposed to traditional French "verrouillage majuscules" Shift lock?

--
Ninho

FFK

Homepage

14.06.2011, 22:16

@ Ninho
 

KBFR 1.9 last beta before release candidate (hopefully)

>
> Thank you for trying out!
> Assuming your trial was run with a real French keyboard connected, did you
> like the feel of the CAPS Lock mode (as opposed to traditional French
> "verrouillage majuscules" Shift lock?
>

Yes it's more modern to enable/disable the CAPS Lock using the same key.
I do like also that there is no ugly beep error if some one push the wrong key for special caracters like 'ê' or 'ÿ'.

ecm

Homepage E-mail

Düsseldorf, Germany,
13.06.2011, 01:06

@ Ninho
 

review

> brand new int 15h method is used to communicate with an installed
> instance of KBFR.

I'm not a fan of overloading interfaces with magic values like that.


orgint15's address is hardcoded in the uninstaller. Why? If you hardcode things, you might as well hardcode the kvar address instead of returning that in your interface.

Your interface still contains some unused fields?

The trans function still isn't inlined, as you noted in the comments.

Your interrupt handler still isn't using the interrupt sharing protocol.

Your uninstaller still doesn't walk interrupt sharing protocol handler chains and doesn't query AMIS TSRs for their chain entries.

You sometimes discard the saved flags by returning with "retf 2" from an interrupt handler.

Your arguably ineffectual critical section protection doesn't appear to be necessary any longer, as you aren't using any data in the freed area. You can use 21.49 to free the previous PSP's area then.

You still free the environment only inside the (non-)critical section, and manually. I'd use 21.49 again.

Where it says "calculate resident size", the calculation always appears to yield the same value so you might as well hardcode (size+15)>>4 with the assembler.

Still not checking for errors after 21.48. Can't happen? I can write a fully compatible TSR which might make just that happen. What then? You'll overwrite 496 bytes at 0008:0000 (linear 00080) then, incidentally trashing interrupt vectors 20h til about A0h.

I guess that's all for now.

---
l

Ninho

E-mail

13.06.2011, 11:24

@ ecm
 

discuss -> developpers' section (NT)

.

Back to index page
Thread view  Board view
22632 Postings in 2109 Threads, 402 registered users, 384 users online (0 registered, 384 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum