> I was trying not to present it until it consists of a significant
> running piece of code, because I don't want it to sound "virtual"
I know what you're talking about here.
> I know that the main objective in FreeDOS is to provide a working
> classical DOS environment and not to turn into "something else". I do
> not intend to go against that aim. However, I do believe that there are
> some important points that do not have any support within classical DOS
> at all and for which a standard should be implemented. I am trying to
> supply that standard in a way that will not "collide" with classical
> DOS, that is, the same code will run the same way, but applications will
> have the option to also rely on a driver and some modules.
Please don't restrict your project just because some people might not like
it, thank you.
> I have been asking questions here to implement two of these modules
> (namely Unicode support [or "Code-1 module"] and a new native DOS sound
> interface [or "CPOS/NSS"]). The driver ("CPOS") would be loading a "main
> module" into conventional memory that would dispatch functions and
> separate them in "knots", each of which would redirect to a "child
> module". These modules can be programmed separately, but I would like to
> create at least two if them to be presented together with the main one
> as the first issue of CPOS.
What does the Unicode support do? What tables or services are provided by
it?
> The purpose is not only about supporting these items, but about doing
> it in a way that can easily be implemented from different software and
> hardware platforms and still satisfy the standard. This would mean that,
> for example, one single guy might come up creating his own small
> operating system somewhere, without any support from anybody and decide
> to follow the CPOS standard. If he does so, he would be able, after a
> few modifications in the source code, to recompile modules already made
> for another OS and use them in his, so he would have, say, sound support
> in his OS without having to research and program everything himself.
> Additionally, if he would develop a module for, say, DVD burning,
> FreeDOS could use his source and recompile it so that it could be loaded
> and hooked at a knot in DOS/CPOS. In other words, all hobbists in OS
> would be able to cooperate and still we would have diversity, because
> each OS would use their own method to provide CPOS.
And in what language do you implement CPOS? I mean, is it restricted to
386 architectures (i.e. Assembly)?
> In particular, for FreeDOS, I have been thinking this could be
> applied on a real mode interrupt (maybe 2Bh, but could also be 50h) with
> the parameters passed as registers, as it is usual in DOS, but other
> ways could be used instead.
If you search a real mode interrupt, you might consider providing your
interface on Int2D and following the Alternat(iv)e Multiplex Interrupt
Specification (AMIS). This often provides other TSRs and your driver with
the possibility to remove the TSR, and Int2D isn't used by something else.
The most recent AMIS can be found inside the RBIL; read the descriptions
of the Int2D functions.
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
