>    The reason why I've been considering a brand new interrupt is because  
> the driver is not supposed to be single-purposed.

This does not convince me.

> What I want to create is a new standard interface where support for new  
> features can be hooked in a very tidy and organised way. I think we  
> can't just keep on adding functions to the int 21h, because

... almost all functions are already used and really, assigning fixed  
function numbers is no way to go anymore. But anyway, we didn't talk about  
Int21.

> although I know of AMIS and I find it very flexible and useful, the  
> interface is again to big to be put inside an already multiplexed system.

What do you mean here? Do you think there aren't enough available  
functions? Then pass the function number in other registers (besides ax)  
too. Or do you mean it won't be fast enough to call all functions through  
Int2D ? Then let applications request your real entry point with an AMIS  
function on Int2D and provide your own interface at this address. I don't  
see why you have to allocate another fixed interrupt for this.

> I thought of ints 2Bh and 2Ch

Int2C has been used by Cloaking, kind of a DOS extender.

> within the range of the DOS interrupts and the driver would be a field  
> on which to extend DOS, but it could also be done with other interrupts.

Basically, it doesn't matter. Packet drivers and EMM386 use interrupts  
>60h and yet they're considered DOS extensions.

> This spec has a list of general functions and general parameters which  
> is independent from software and hardware.

Consider passing a request structure to the interface then. Opposed to  
specifying interrupts to be called and registers to be used, this could  
easily be adapted for other architectures.

> I could create
>  patches to replace these drivers and take the output to the new module.  
> DOS would have sound again... always, and without need of port emulation.

Except with existing programs that directly access the hardware and don't  
use any of these specifications.

Regards,
Christian

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to