> I'm thinking that I can perfectly get an interrupt, without having to > reserve one. That is, a function under AMIS could tell the driver to get > hooked at a certain interrupt chosen by the caller. This would be more > comfortable for the high-level programmer than having to call an > absolute address.
No. It might be more comfortable for a low-level (i.e., Assembly) programmer. It doesn't make a difference in high-level languages. Also, the caller would have to find a free interrupt at run time, which might create new problems. > When I said "already multiplexed", I meant that my driver is itself a > multiplexed system, because it can load and unload modules and manage > their functions. Okay. > The modules are not TSRs that have to load on top and create a chain, > but instead, are dynamic Which is different from TSRs in what way? TSRs don't have to be restricted to load in a specified order. > and are called in parallel. Do you mean they're called in the background? What does "parallel" mean here? > Their codes are never executed unless a specific function is invoked and > the modules only remain in memory while in use. So you have to load them from the disk when they're requested? I don't object to this approach generally, but keep in mind that loading files must happen in the foreground. > Anyway, I don't think that is necessary. The reason is that old DOS > applications that use sound can be divided in games and non-games: > oldest games are the ones that do not use 3rd party drivers, but the > easiest to modify and most support PC speaker anyway. If the game supports SB or AdLib sound, the PC speaker output won't be as good as the SB/AdLib one. About patching old games: Maybe you're right about this and it'll work for most games. Either way, I'm looking forward to an implementation of this architecture. 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
