Guys,
I am currently working on a project for DOS and I hope the FreeDOS community
will find it useful. 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",
but as I ask for help here, people ask me details about it and I believe it is
fair for you to know more if I am needing your help or answers.
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.
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.
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.
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 any of all this sounds silly, I must apologise that I have not been able
to be specific enough here or describe exactly how the driver would work, as I
am not providing code right now, but I will eventually do and I am from this
moment appreciating any suggestion, comment or question.
Thank you very much in advance for your help and sorry about my not being
able to upload a neat piece of code right now.
Lucas
------------------------------------------------------------------------------
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
