Re: [Freedos-devel] Calling interrupts when iddle

[Christian Masloch]

> It's not that I want to stop, but just be nice to others. If they
> don't exist, I assume it'll get back to me fast.

Not halting will unnecessarily spin through CPU cycles and energy while  
the program is idle. Halting instead is less costly.

Regards,

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] About Bret's license

[Christian Masloch]

> Don't forget
> http://www.osor.eu/eupl/european-union-public-licence-eupl-v.1.1 for
> European developers, because it's compatible with GNU GPL v2 and is
> available in 22 languages.

I think you're allowed to use it even if you're no European citizen,  
aren't you? Still, isn't it GPL v3 incompatible or something? (There might  
be a workaround using one of the other compatible licenses.)

Regards,
Christian

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] About Bret's license

[Christian Masloch]

As this is about software licensing issues, I want to state here: I'm not  
a lawyer and this e-mail does not contain any legal advice. Oh, and if  
you're easily annoyed by licensing issues then you might prefer not to  
read this thread.

In "FreeDOS 1.1 (again)", dos386 wrote:

> Bret's USBDOS (free & OS, not GPL)

I'm not sure whether Bret's license would be accepted by the OSI or FSF  
though. The part that I'm concerned about most would be this:

> You can use the programs
> without restriction, but you cannot directly or indirectly use the
> executable programs, documentation, or source code to create or
> distribute new programs that are not also freely available.  You also
> cannot distribute the programs, documentation, or source code and charge
> (even indirectly) for their distribution.  You can charge someone enough
> to cover your actual, direct costs for distribution (disks, shipping
> materials, postage, etc.), but cannot charge for "handling".  This also
> means that you cannot distribute the programs, documentation, or source
> code directly from a web site that charges a "registration fee" in an
> attempt to make a profit or to recover direct or indirect costs for
> maintaining the web site.

Specifically, "indirectly using the programs to create or distribute new  
programs that are not also freely available" sounds to me like the  
license's copyleft covers _using the programs to program or distribute  
other programs_. If that is the case, you should think twice about using,  
say, USBKEYB to develop programs, or USBDRIVE to store them on USB storage  
media.

(Generally, this copyleft may or may not make this license incompatible  
with other copylefted licenses such as the GPL. GPL incompatibility of  
course would not be a criterion for exclusion.)

Moreover, I have a hunch that the no-selling part, in this form, is not  
compatible with at least some OSI and FSF licenses, and might entirely  
cause the license not to be considered "free software" by the FSF and  
"open source" by the OSI.

> If you distribute related or derivative programs, you must use
> essentially the same license.

Could be understood to apply to programs that only use, for example, the  
API provided by the USB HCI drivers. There might be no FSF or OSI issues  
with that, because GPL libraries extend their copyleft to API users and  
the GPL is allowed by both organisations. However, the wording "related"  
might be too broad. It could even apply to programs only interfacing with  
the USB programs via command line.

> You must provide and distribute the
> programs and documentation for free, and you must include the
> documentation with the program.

This is misleading: Would one have to include the documentation even if  
one extracted a small part of the code and distributed that as part of a  
small program? Moreover, would one have to provide the original  
documentation in all cases? (Of course, such a strict requirement should  
at most apply to the license text and copyright notices.)


Yes Bret, I know you don't want people to search for loopholes (as is  
stated by the license text; it is "writing down the intent"). And I admit  
that some of my points might be just such minor loopholes that the intent  
is clear. But I'd prefer* the license to state some of its intents more  
clearly, and I want to know what FreeDOS's developers think about  
including programs with this license.

[ * Personally (egoistically), I'd rather prefer the programs to be in the  
public domain, or the license to be one of the well-known free software  
licenses (MIT-style, 2/3-clause BSD, etc) that do not cause trouble, or  
even other (common) ones like the GPL. But of course there's reasons not  
to do that, too. ]


What do you people think? (And who's responsible for such FreeDOS  
project/distribution decisions?)

Regards,
Christian

--
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces?

[Christian Masloch]

CM>RBIL> on DOS versions which do not support the FAT32 calls, this  
function
CM>RBIL>  returns CF clear/AL=00h (which is the DOS v1+ method for  
reporting
CM>RBIL>  unimplemented functions)
CM>
CM> You have to be careful about this criterion. My observations indicate
CM> that
CM> DOS versions that do not support interrupt 21h function 73h indeed  
return
CM> with an MS-DOS v1 style error, but that does _not_ mean CF clear and AL
CM> zero. It means AL zero and CF unchanged.

JM> I set CF to 0 before I started, and I got 0 when I ended.  windows xp.
JM> xp totally blew the function call.

No, you did.

Please re-read the quote above to understand why Windows XP's NTVDM, to  
indicate an error, left CF at what you set before (in this case, zero).

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces?

[Christian Masloch]

> 1. ax=7300h dl=0 cl=1 int 21h - if it returns ax unchanged,
> then the kernel is not aware of the 21.73xx FAT32 functions.

Why test another function (which is really undocumented at that, so  
unlikely to be implemented properly in other DOS versions) to determine  
whether function 7303h is supported? I mean, sure, it might work. Just: is  
there any advantage to it? I don't see one.

I'd set ax=7303h, ds:dx->, es:di-> and cx as appropriate and CF=1. If CF=1  
on return, there was an error. The error code in ax can be used to  
determine whether the function is supported but caused an error, or  
whether it is not supported at all. In the latter case ax equals 7300h (or  
even 7303h) or 0001h.

Regards,
Christian

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces?

[Christian Masloch]

> RBIL is pretty much it (right? or some "undocumented" book, perhaps?),
> and it doesn't say much that hasn't already been mentioned.
>
> http://www.delorie.com/djgpp/doc/rbinter/id/40/32.html

For completeness, here's the original site (right?):  
http://www.cs.cmu.edu/~ralf/files.html

The book is called "Undocumented DOS", but was written around 1993 (2nd  
Edition here). It contains material about MS-DOS 6.2, as well as  
discussing predictions of the upcoming "Chicago" operating system (to  
become Windows 95 and MS-DOS 7.00). Therefore it does not contain any  
information about the Int21.73 interface or FAT32. Here's a link to  
Amazon's description of the book, because apparently there's no Wikipedia  
article about it:

http://www.amazon.com/Undocumented-DOS-Programmers-Structures-Programming/dp/020163287X

Regards,
Christian

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] documentation for FreeDOS filesystem or other programming functions/interfaces?

[Christian Masloch]

> I am possibly going to rewrite my df utility to work with freeDOS' FAT32
> filesystem (DJGPP uses int21h function 36h which is 16-bit FAT16 and  
> 16-bit
> regs).
>
> I cannot find any documentation on the functions that freedos uses for  
> its
> filesystem functions, like getting filesystem volume space calculations  
> (total &
> available).
>
> can anyone help me?

Yes.

Refer to Ralf Brown's Interrupt List's description of interrupt 21h  
function 7303h. (This is also referenced in the SeeAlso section of the  
description of interrupt 21h function 36h.) The data returned into your  
buffer by this function is partially different to that returned by  
function 36h, but testing this on a FAT32 file system and verifying  
whether the results match your expectations should work. I think to recall  
that on DOS versions that support function 7303h you can usually obtain  
information about FAT12 and FAT16 file systems using this function too.

As to your exact request for a FreeDOS function, FreeDOS kernels with  
FAT32 support provide function 7303h. They also allow retrieving  
information about non-FAT32 file systems this way.

Note that RBIL says:

> on DOS versions which do not support the FAT32 calls, this function
>  returns CF clear/AL=00h (which is the DOS v1+ method for reporting
>  unimplemented functions)

You have to be careful about this criterion. My observations indicate that  
DOS versions that do not support interrupt 21h function 73h indeed return  
with an MS-DOS v1 style error, but that does _not_ mean CF clear and AL  
zero. It means AL zero and CF unchanged.

Regards,
Christian

--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] ASCII to unicode table

[Christian Masloch]

> You would need an Input Method driver which lets you type
> complex key sequences or combinations to type in a language
> which has more than the usual few dozen chars of alphabet.

Yes. The (keyboard) input and (screen) output appears to be the most  
complicated exercise here. DBCS or UTF-8 support inside other programs  
would appear less complicated - as far as I know, DOSLFN properly supports  
DBCS. (UTF-8 appears to be easier than DBCS, but I didn't look into the  
details of the latter.)

> In addition, you get a sort of graceful degradation: Tools
> which are not Unicode-aware would treat the strings as if
> they use some unknown codepage. So such tools would think
> that AndrXX where XX is an encoding for an accented e has 6
> characters but at least you can still see the "Andr" in it.
>
> In the other direction, if you accidentally put in a text
> with Latin1 or codepage 858 / 850 encoding, you get AndrY
> where Y is the codepage style encoding of the accented "e"
> and the Y and possibly one char after it would be shown in
> a broken way by a CON driver which expects UTF8 instead.

Arguably, the UTF-8 "compatibility" is worse here: with the actual  
encoding in any code page (not DBCS or UTF-8), displaying the string in  
another code page will replace each non-ASCII character by one random  
character of the active code page. With UTF-8, non-ASCII character are  
encoded as multi-byte sequences - resulting in several random characters  
of the active code page, where actually only one code-point is encoded.

> I do not understand the "codepoints are 24 bit numbers"
> issue. Unicode chars with numbers above 65535 are very
> exotic in everyday languages

That is why I said it's not that important.

> If you mean UTF8,

No. That would not make sense. A code-point is usually written like  
"U+0038", with 4 to 6 hexadecimal digits that give you the numeric value  
of that code-point. The "character set", Unicode, defines code-points. The  
encoding, UTF-8, defines how (almost) arbitrary numeric values are to be  
encoded into a stream of bytes. UTF-8 support easily scales to support all  
currently reserved code-points which do not fit into a 16-bit number, if  
the underlying interface supports them. (A 21-bit number is large enough  
for all code-points.)

> I think Mac / Office sometimes might use
> one of the UTF16 encodings but otherwise they are not
> so widespread.

Don't forget FAT's long file names ;-)

Regards,
Christian

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] ASCII to unicode table

[Christian Masloch]

> Combined with, for example, a UTF-8 enabled Super-NANSI to
> make the step from strings to their display, of course. The
> problem would be loss of "ASCII" art block graphics in apps
> which are not using Unicode.

But that happens for some code pages anyway. (For example, CPs 858 and 850  
drop some of the CP 437 block graphics. CPs that need more characters  
probably drop all of them.)

> A possible workaround would be
> dosver-style, to make a per-app decision who uses Unicode.
>
> [...]
>
> Some old apps will only use ASCII anyway which is the same
> for real ASCII and for UTF8 but some others will assume a
> codepage (often 437) to be active. The block graphics and
> other chars from the non-ASCII half of any codepage differ
> in encoding from UTF8 so, as said, any display or similar
> driver would need some way to switch between "classic code
> page mode" and "UTF8 rendering mode". It could switch on
> UTF8 based on explicit request from a modern app or based
> on app name for old but known compatible apps... It would
> switch off UTF8 when any app exits (int 21.4c / 21.31...).

I don't like such an approach. You would have to keep the current status  
in a PSP field. And even then, pop-up TSRs might *interrupt* the currently  
running process (without switching the PSP or saving/restoring other  
fields). One of the TSRs I'm regularly using displays its pop-up using  
block graphics.

I'd propose to use a new interface instead - this new interface then  
always uses UTF-8, the normal one will use code pages (or reject  
CP-dependent characters). (Of course using only ASCII it doesn't matter  
which interface you use.)

> If yes, I do
> assume that the LFN API already is explicit about whether
> UTF8 or rather codepage style encoding should be used?

The DOS LFN API works with code page encoded strings.

Regards,
Christian

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] ASCII to unicode table

[Christian Masloch]

> I think your attitude is not very constructive. We have to keep this  
> idea as simple as possible or nobody implements it.

I think some of that is important, even if you only want to implement a  
simple translation. Besides, of course it isn't very constructive to  
*discuss* an idea. Go use DOSLFN's source (free/PD) and implement an  
interface if you want to be constructive, should be enough pointers here  
by now.

> I think it is not needed to make tables UNICODE to ASCII.
> It is sufficient to make ASCII to UNICODE.

Please be specific, I think what you are saying is not what you mean.

I assume that when you say "ASCII" you mean "current code page" because  
ASCII to Unicode (and the reverse) translation doesn't require any table  
at all. Strictly, the ASCII contains a set of 128 codes - these all have  
the same numeric value as the associated Unicode code-points.

You might be proposing that the implementation should be, as Bret put it,  
"accurate" - ie it should only map exact matches, ignoring "pairs of  
characters that look similar enough" (Bret's "useful"). The literal sense  
of your words is that the implementation should be unable (!) to look up  
what a particular Unicode code-point should be mapped to in the current  
code page (only accurate matches). This is undesirable as it would  
unnecessarily hinder many applications.

> Simple table - on one side 256 bytes - on second side 256 words.
> That is all.

You actually need only 128 words for what you have in mind - the lower 128  
word table entries can be dropped, because the ASCII characters/bytes  
always map directly to Unicode code-points. The byte table (containing the  
associated byte in the current code page) can be dropped entirely, because  
its contents will just count upward.

(That table format matches what DOSLFN uses for simple (256-character)  
code pages. DBCS mapping needs to be a lot more complicated. Though you  
might not care, I suggest one consult DOSLFN's source if one is interested  
in DBCS mapping.)

As I mentioned, with a table consisting of (16-bit) words for the Unicode  
side you cannot map all Unicode code-points. Granted, this is not very  
important in practice.

Regards,
Christian

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] ASCII to unicode table

[Christian Masloch]

> UniCode is not the panacea it's purported to be.

No, but you have to give them that it's certainly an improvement.

>> UTF-8 is independent of byte-order. The exact encoding (and byte-order)
>> should always either be implicit (in the interface's or format's
>> definition) or be marked in some way.
>
> I don't think there is a way to automatically determine the encoding from
> the data itself,

Yes, you cannot reliably automatically determine encoding. That's why I  
said you should *know* what data you deal with. (Automatic determination  
of encoding is a serious problem in dealing with plain text files, but  
that need not concern a kernel code translation interface such as the one  
I have in mind.)

> and the only way to determine the byte-order (assuming it's
> not UTF-8, not a single character, and is unknown from the context) is to
> include the special BOM (Byte Order Mark) character as the first  
> character
> of the string.

Yes.

> In fact, according to the UniCode spec, if the BOM is not
> included and the byte-order is not clear from the context, you're  
> supposed
> to assume big-endian.

I don't know about that. But I guess that is the case if you say so.

> For file system and similar applications, the interface could just always
> assume a specific format (probably either UTF-8 or UTF-16LE).

Yes. For example, the (in)famous FAT "long" file names are stored in  
UTF-16LE. Their length is determined by their ASCIZ ("UTF-16LZ") nature ie  
they are terminated by a 16-bit word of the value zero.

If a file system interface (such as Int21/Int21.71) was to be made  
Unicode-capable I would probably use UTF-8. (Particularly because of the  
ASCII compatibility, where only characters >= 80h ("codepage-dependent" so  
to speak) represent code-points >= U+0080.)

> For a
> general-purpose interface, though, you should be able to handle all
> different kinds of possibilities (including things like "UTF-24" and
> "UTF-64").

UTF-24 would be pretty funny. (FAT24 is an actual idea I had. Would work  
well enough.) Even theoretically, UTF-64 doesn't make a lot of sense: a  
24-bit (let alone 32-bit) encoding can already represent more values than  
are currently reserved for all Unicode code-points. Alignment of each  
single code-point is no particularly good reason to unnecessarily double  
(you might speak of "bloat" (-; ) the space required to store any given  
string. 64-bit alignment of the whole string can still be achieved by  
storing an unused dword behind the actual string if it contains an odd  
number of dwords; accesses can be aligned by always accessing a whole  
qword then selecting the appropriate dword and discarding the other.

> Also, even though you're dealing with DOS doesn't necessarily
> mean everything will be little-endian -- it depends on the source of the
> data.  Certain hardware interfaces (like SCSI) are inherently big-endian,
> and data downloaded from external sources can be almost anything.

Yeah.

> Another possibility is what my UNI2ASCI program does, which is accept
> strings terminated with a specific character (in my case, the UniCode NUL
> character, conceptually similar to ASCIIZ).  A general-purpose program
> should provide more than one way to define a string's length.

I guess specifying the length in bytes is good enough. If you want to  
provide such an interface NUL-terminated (or CP/M-style dollar-terminated  
(-; ) strings, write a wrapper function which counts the number of non-NUL  
bytes/words/tri-bytes/dwords/qwords before passing the string to that  
interface. For non-UTF-8 Unicode encodings, a number of bytes not  
divisible by the length of the expected units (2, 3, 4, 8) could just  
cause an error.

Generally speaking, error handling is important. Correct UTF-8 validation  
isn't pretty though.

> If you limit
> input to only certain encodings or byte-orders or string/character types,
> then it ceases to be "general-purpose".  Maybe a general-purpose program  
> is
> not what we're really talking about here, but I think one needs to be
> developed.

Yes, yes. I don't think a general-purpose translation program is what was  
initially suggested (correct me though).

Regards,
Christian

Just noticing that this grows quite large. If someone finds this  
unbearable for this list, please speak up to let me know I should cut down  
the off-topic stuff on my public mails!

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] ASCII to unicode table

[Christian Masloch]

> Should the translation be "accurate" or should it be "useful"?

I think it should be accurate for file systems. Such a "useful"  
translation is a good concept for displaying output (maybe even that of  
the DIR command) but not for actually working with the file system.  
Keyboard input can't map one key to several characters at once (unless you  
randomly (-; decide which one to use) so input handling should use  
one-to-one translation too.

> From a technical perspective, you will also at a minimum need to concern
> yourself with translating strings vs. translating single characters  
> (UniCode
> strings can/should include an Endian-defining character at the  
> beginning, as
> well as needing to define how the length of the string is determined),  
> UTF-8
> vs. UTF-16 vs. UTF-32, and Big- vs. Little-endian.  None of this is  
> trivial,
> and I think this is WAY too complicated to be in the kernel -- it should  
> be
> a separate program/driver.

UTF-8 is independent of byte-order. The exact encoding (and byte-order)  
should always either be implicit (in the interface's or format's  
definition) or be marked in some way. The definition of a string's length  
(possibly number of bytes/words/dwords, number of code-points, number of  
"characters") need not be addressed by such an interface. If there is a  
need for a buffer or string length (see below) a new interface should just  
define that all "length" fields/parameters give the length in bytes.

If there was a DOS (kernel) interface, it should probably accept a single  
character (usually one byte, two byte for DBCS) encoded in the currently  
selected code page and return a Unicode code-point. All code-points fit  
into a 24-bit (= 3-byte) number; though such an interface can be limited  
to Unicode's BMP (16-bit numbers (= words)) like the DOSLFN/VC tables. Of  
course there should be an "accurate" reverse interface which accepts a  
24-bit (or 16-bit) number and returns a one- or two-byte character in the  
current code page if one exists for that Unicode code-point.

Notably, some code pages might contain characters that should map to  
several code-points and some code-points might require more than two bytes  
when represented in the current code page's encoding. A string translation  
interface might therefore be more appropriate. (As an aside, this would  
solve the need for a DBCS kludge because multi-byte mappings could be  
supported intrinsically.) In this case, the interface should exactly  
define what Unicode encoding to use (UTF-8, -16BE, -16LE, -32BE, -32LE) -  
applications have to figure out on their own what encoding their data uses.

Regards,
Christian

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] ASCII to unicode table

[Christian Masloch]

> Now programs do it self by looking into own datafiles with .TBL  
> extension. Look at DOSLFN or Volkov commander 4.99. They have few files  
> like cp852uni.tbl, cp866uni.tbl and so on.
> It is a very good solution but problem is that here is no way now how to  
> determine which file should be used.

At least DOSLFN queries DOS for the currently used codepage and tries to  
load that table. This query is in its Int21 handler so it will catch  
codepage changes and try to load the new table then.

> It fully relies on manual configuration.

No.

> Anothor point is that ASCII-unicode conversion should be somewhat  
> treated by OS, I think. I think it is not smart if every unicode program  
> has own TBL library. It should be one somewhere in FREEDOS derectories.

Yes.

> So how to solve it?
> * let the user call function for international info, and by returned  
> codepage manualy decide which .TBL file to use?

As currently done by DOSLFN.

> * .TBL files should be in LANG or NLSPATH environment variable?

A centralized location might be useful. It might also be possible to  
create a file format where several tables share one file. I think such a  
format could be a COUNTRY.SYS extension without breaking other users of  
that file.

> * somehow extend the kernel function for international info to say which  
> .TBL files to use?
> * preload .TBL into memory in COUNTRY initialization and even more  
> extend international info to provide ASCII-  unicode conversion?

Both would be useful. Such a table (if limited to Unicode's BMP, as  
DOSLFN's format currently is) needs 256 byte plus some info like what  
codepage the currently loaded table corresponds to.

Regards,
Christian

--
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] C/C++ BIOS backup

[Christian Masloch]

> I read through the boot code and didn't see and specifics written
> about where the system bios is stored in memory.

The boot code uses the software interrupts associated with the BIOS to  
call BIOS functions. For example, interrupt 16h (BIOS keyboard functions)  
and interrupt 13h (BIOS disk access functions). This is why the BIOS's  
location is only implicit in the boot code.

> I'd like to backup a copy
> of the bios and have a look-see through the file. Does anyone have any
> recommended algorithms for such an exploration?

I don't know what you mean by "backup". An actual backup would need the  
ROM chip's content. Direct access to that chip differs from vendor to  
vendor. I suppose its content is not necessarily the same as the part  
mapped into memory while an operating system runs. The mapped ROM is  
usually at segment F000h, or linear address Fh, or 960 KiB. These all  
mean the same thing.

If you are not interested in actually backing up your BIOS and rather only  
want to explore it, I'd recommend you use (FreeDOS) DEBUG to do that. You  
can use it for single-stepping through the BIOS; normal breakpoints can  
not be set in ROM though. (This means the P and G commands can't be used  
if their breakpoint(s) are to be written in the BIOS's code.) For this  
reason, just stepping into parts (or looking the addresses up in the  
interrupt vector table) then disassembling from there might be easier for  
exploring how the BIOS works.

If you are not familiar with the software interrupts associated with the  
BIOS, look them up in Ralf Brown's Interrupt Table.

Regards,
Christian

--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] C/C++ BIOS backup

[Christian Masloch]

> each bios is going to be different.  what is common between the BIOSes  
> is the
> int21H functions, which are outlined here:
> http://hdebruijn.soo.dto.tudelft.nl/newpage/interupt/out-0100.htm

Interrupt 21h is provided by DOS. The list you link to contains BIOS  
functions as well as DOS functions (and a heap of others).

Why do your mails contain your address in the Reply-To field? Doesn't that  
create redundant traffic to you (assuming you properly subscribed to the  
list)? Should we drop it?

--
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [Freedos-user] svn failure

[Christian Masloch]

> How can I deal with an improper file name?

This is probably a question you should rather ask the TortoiseSVN guys,  
but I found the relevant section of their FAQ:

http://tortoisesvn.tigris.org/faq.html#cantmove

It links to this, which is a workaround for improper file names but  
requires write access to the repo:

http://tortoisesvn.tigris.org/faq.html#casechange

Since you only have read access, I would recommend downloading the file  
manually - renaming it to a valid name - and instructing TortoiseSVN to  
download every file and directory except the one with the improper name.  
You could also download every file and directory from SF.net - that  
probably is more work though. Notably, SF.net allows you to download a  
(.tar.gz) archive of an entire directory - you could download the entire  
repo this way, then extract all files and directories except the one with  
the improper name with your favourite archiver. The difference would be  
that the files ain't managed by TortoiseSVN then.


What might be the more relevant question is, why is there a file named  
"..." in the repo? (The path is mem/branches/mem14/) Its contents appear  
to be a zip file, though 7-Zip reports it as invalid. Notably, all bytes  
with the value 13 (CR) in the file are followed by bytes with the value 10  
(LF) which is probably an incorrect conversion done by the SF.net web  
interface, or by the uploading SVN client or the server. Examination of  
the file leads me to believe it is a source package of fdxms, which  
probably does not belong in the mem tree. So it appears the file is both  
improperly named (for Windows/DOS) and does not even belong into the repo.  
Maybe some developer knows more about the file.

Regards,
Christian

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] [Freedos-user] Regarding dot and dotdot entries

[Christian Masloch]

DOS386 (on Freedos-user):
> [...] the great "." and ".." AKA "dot" and "dotdot" entries are  
> inherently
> useless and many DOS and non-DOS kernels do ignore them mostly or fully.

I think that there are drivers/systems that will just expect both entries  
to reside in the first two directory entries. This means they would not be  
able to access real files stored in these entries, and their tools (such  
as the RD command of FreeCOM) would delete non-empty directories thinking  
they were empty if only the first two entries hold files.

Regards,
Christian

--
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Standardized development tools

[Christian Masloch]

> Now, I will have to disclose that I have not tried jwasm.  There's no  
> reason
> behind that except for laziness.  Having learned nasm and finding it met  
> my
> needs, I just didn't try jwasm because I didn't want to learn it.  So, I
> cannot compare nasm to it.

I can't really compare NASM to it either, because I never really did any
serious programming effort in MASM/TASM/etc. However, it looks like JWASM
provides a high degree of compatibility with MASM. Apparently it can
already be used as a drop-in replacement for lots of existing code. This
means that JWASM is essentially the best free MASM-syntax assembler.

> Given my druthers, I would like to see nasm as the standard for the
> project.  Again, this is only for what is currently on SourceForge.net  
> and
> maybe the base in the future, but that is a personal choice and not one
> scientifically arrived at.  I could be wrong.

I never would do any assembler programming in any other assembler than  
NASM either, but a lot of other programmers still prefer MASM. To note one  
example, Japheth maintains the most recent EMM and HIMEM drivers for  
FreeDOS as well as the HDPMI DOS extender/DPMI server. (Not incidentally,  
he created/maintains JWASM too.)

Regards,
Christian

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Standardized development tools

[Christian Masloch]

> I'm thinking it would be a good idea to standardize on one C/C++ compiler
> for the project. [...]

I would be interested in your opinions about standardizing one or several  
assemblers for the project. I think that the kernel and FreeCOM assembler  
source files currently use NASM, a 2-clause BSD licensed assembler.

NASM uses a slightly different syntax than the one of MASM that most DOS  
programmers were used to. A free assembler with nearly the same syntax as  
MASM is Japheth's recent JWASM, an extended fork of Open Watcom's  
assembler. It is distributed under the same license as Open Watcom.

I propose that any assembler source code added to the project should be  
compilable with either NASM or JWASM. (It might be useful to some that  
NASM also provides limited TASM compatibility; refer to its documentation.)


I have another concern regarding the use of inline assembler code in C  
source code, as mentioned in this thread. While reworking current code  
isn't required, please consider to implement functions you might write  
with inline assembler code either in pure C or pure assembler.

In the later case, that source code should be moved to a proper file on  
its own. That file would be compiled into an object format using one of  
the stand-alone assembler. This might also make such functions easier to  
port to other compilers or platforms since the porter won't have to look  
through C source files for inline assembler code.


An off topic question: Is there any source code in the full distribution  
that uses C++ and OOP?

Regards,
Christian

--
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New Distro: checking everything

[Christian Masloch]

Hi Alain,

> JEMMEX crashes XMSDSK, so it could crash other programs and I did no
> further test.

I often use both together without issues. Maybe you could report the bug  
that you experience? When did you test JemmEx?

Regards,
Christian

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Pre-presentation of a project

[Christian Masloch]

> I'd better put up the code. I don't want to be all theory up here.

I'm fine with theoretical discussions.

> Even though you first said I shouldn't change my project just because  
> some people may not like it, and I agree, I also believe it is very  
> important to check with you guys and to be constructively criticised  
> here.

Well, it should certainly be your decision. No matter what, some people  
(possibly including me) won't like it. If you prefer things I don't like,  
please don't change them just to satisfy me.

>Of course, the main module is itself a TSR and TSRs could perfectly  
> work in this fashion, but it is not what usually happens. I normally see  
> new code hooking up an interrupt, making a function ID comparison at the  
> beginning and jumping to the old handler if this is not the function it  
> is interested in. This generates a slow serial chain of handlers. I want  
> to avoid that.

Your interface (as I understand it) isn't that different. Somewhere you  
have to dispatch into different modules.

>OK. I'll work on the AMIS interface for the first implementation of  
> the main module. I'll post it when I have it and then start the Code-1  
> and NSS.

If you're interested, I could send you descriptions and example source of  
some TSRs and AMIS implementations that I worked out with Bret. This TSR  
installation method always allows the program to install its resident part  
into the best location. Installation into a UMB works without LOADHIGH.  
The deinstallation method allows to remove the TSR even if other TSRs were  
installed later depending on the type of these TSRs.

Regards,
Christian

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Pre-presentation of a project

[Christian Masloch]

>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

Re: [Freedos-devel] Pre-presentation of a project

[Christian Masloch]

>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

Re: [Freedos-devel] Pre-presentation of a project

[Christian Masloch]

> 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

Re: [Freedos-devel] Fw: Re: About my driver, HIMEM/EMM386 and interrupts

[Christian Masloch]

> Is there any site where I can read in very good detail and in a way that  
> is easy to understand, how flat-real mode, VCPI and DPMI work and how  
> they deal with other previously loaded systems to avoid collisions?

I don't know about such a site. RBIL however provides much information  
about the VCPI, DPMI and XMS interface each. If you can read Assembly, you  
can also look at the source code of HIMEMX, JEMM and HDPMI.

>DOS386 mentioned "if you want PM, you have VCPI", I think, meaning if  
> I wanted to access PM memory. If that is the case, that line is indeed  
> very significative to me!  Only I wish I knew more about VCPI.

Read the RBIL description of the Int67.DE functions.

>One doubt I have about XMS functions is this: the XMM specification  
> states that if I lock some memory, I must unlock it as soon as possible.  
> How soon is that?

I think it doesn't have to happen at all. You don't even have to unlock  
the block before deallocating it (when your driver is removed from  
memory). Someone else might know about that better.

> What exactly is a lock count?

The lock count is incremented each time you lock that memory block. Each  
time you call XMS to unlock the block, it's lock count is decremented.  
Only if it reaches zero, it's actually unlocked. This way the owner may  
lock the block multiple times but it really is unlocked only after  
unlocking it as often.

In case you thought about it as some kind of timer: no, it isn't.

> I may, for many things, not need to know where my memory block is  
> located, but sometimes, when I do need it, it would be important to keep  
> it locked for as long as the driver is running, because it is a driver  
> and other programs would be relying on it.

You could require these programs to register as soon as they want to use  
the driver, and unregister when they're done using it. (You may want to  
lock XMS memory blocks the whole time anyway though.)

> Can I keep memory locked like for the whole time one process is running  
> (i.e.: half an hour)?  How bad is that?

As mentioned, I think that's allowed.

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

Re: [Freedos-devel] Fw: Re: About my driver, HIMEM/EMM386 and interrupts

[Christian Masloch]

>> but then virtual-86 mode is set and I can no loger use 32bit real-mode  
>> pointers!
>
> IF you need PM from V86 there is VCPI.

Protected mode isn't the same as flat real mode.

>> Yet, there has to be a way, because HIMEM works even though EMM386 is  
>> loaded.
>
> As said, it uses INT $15 / AH=$87 then. That's also what you can use
> to access
> PCI memory mapped I/O (>= 2 GiB) from real mode code, even if EMM386 is  
> there.
>
> BTW, RBIL is wrong here, it says "linear address" but the call in fact  
> eats
> physical addresses, at least those above 1+1/16 MiB AKA $0011'.

Yes, you're right. All areas above the 1088 KiB (- 16 byte) accessible in  
real mode access the physical memory. Since the XMM works by switching to  
protected/flat real mode (without remapping memory) or using Int15.87  
provided by EMM386, the linear address returned when locking a XMS memory  
block should be usable as physical address as well.

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

Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts

[Christian Masloch]

>When you say a program would still need to set up flat real mode, I  
> suppose you mean that they still need a jump to protected mode and back  
> to initially setup the segment registers.

Yes.

> However, I understood that HIMEM did something like establishing a  
> routine that was run whenever you tried to use an offset greater than  
> 0h together with a "real-mode-made" segment. This routine would  
> "trap" the event and handle the switch to protected mode and back,  
> keeping the segment base, but extending the limit to 4G, then returning  
> to the instruction that generated the exception. Am I right?  Does this  
> really happen?  If so, programs should not mind about their segments  
> being initially setup in real mode.

No, I'm not aware of any Extended Memory Manager (XMM) that does such a  
thing.

>I agree that using the EMS functions would make the interface lack of  
> good compatibility and would like to avoid that. What I don't want is to  
> do something that will not work if EMM386 happens to be running. I  
> believe that, while EMM386 is running and the system is in virtual-86  
> mode, it is no longer possible to extend the segment limits to 4G and  
> they will always generate the exception. This makes me wonder how come  
> everything still seems to run properly (programs that use XMS) when EMM  
> is there.

You're correct that with EMM386 (which sets up DOS to run in v86 mode),  
others can no longer set up flat real mode. I don't know whether such a  
thing as flat v86 mode is possible, but if it is you'd certainly have to  
work together with EMM386 to get there.

I don't know whether Microsoft's HIMEM handles it the same way, but HIMEMX  
determines whether the CPU is currently in real or protected mode first.  
If it's in real mode, HIMEMX sets up flat real mode (it can be build to  
use protected mode instead) and does the XMS move itself. If it's in  
protected mode, HIMEMX simply calls Int15.87 (BIOS Move extended memory).  
Int15.87 is hooked by EMM386.

EMM386 internally just catches this request and handles it with its  
protected mode code. Note however that EMM386 sets things up so anything  
runs inside protected mode all the time. v86 mode is just a fast emulation  
of real mode that runs in protected mode.

>My driver is a set of functions that use 32-bit registers and runs  
> hooked on a single interrupt. Sometimes the caller will provide a  
> pointer to a buffer and the functions will fill these buffers, but also,  
> some very big tables have to be loaded, that can occupy as much as one  
> or two megabytes.. I could do moving parts of them to conventional  
> memory as needed, but it would be faster if I could access them directly  
> somehow. The driver leads with a sound interface sometimes and needs to  
> set up big buffers that, depending on the sound card, may have a fix  
> hardware address beyond the conventional and high memory limit.

Is this some sort of mapped I/O space for the hardware, or do you actually  
have to allocate a buffer at this address?

Also, doesn't the hardware work with physical 32-bit addresses? If that's  
the case, notice that in any protected mode environment (and flat real  
mode too?) memory might be remapped. For example, EMM386 maps extended  
memory into the UMA to provide UMBs for the v86 mode DOS. Since the  
physical address used by the hardware still accesses the ROM or RAM that  
was in the UMA before EMM386 remapped UMBs, access to EMM386 UMBs with  
physical addresses doesn't work. Potentially extended memory could be  
remapped too.

> Basically, the driver may return pointers to these areas, but could also  
> copy the data to a buffer provided by the caller.
>Do you think I should write the functions like pure real-mode code  
> that accesses HIMEM XMS functions as needed to move the data?  Would  
> that be entirely compatible with real-mode- as well as DPMI-applications  
> calling the functions?

Yes, using HIMEM exclusively is compatible with both real mode and DPMI  
applications. That would of course require the user to load some HIMEM  
program, but I think that isn't too restricting. There aren't many reasons  
you wouldn't want to load any HIMEM.

Note that if you lock your XMS memory block (XMS function 0Ch), HIMEM  
returns the linear 32-bit address of that block. DPMI applications can  
benefit from locking the block because you can provide them the linear  
address (as well as the XMS handle). This linear address can then be used  
in the DPMI environment to access the memory block directly. (For this,  
the DPMI application allocates a LDT descriptor (Int31.) and sets its  
base (Int31.0007) to the provided linear address as well as the limit  
(Int31.0008) to one large enough to access the memory block.)

> If so, how should I handle the events when I need to read or write in a  
> fixed extended memory area?

You're right, this can't be handled with XMS functions. Yo

Re: [Freedos-devel] About my driver, HIMEM/EMM386 and interrupts

[Christian Masloch]

>I'm building a driver (for DOS) that's supposed to have several  
> functions hooked at an interrupt. When applications call these  
> functions, the driver should load and unload some tables or  
> activate/deactivate them somehow. Because these tables are big, I don't  
> want to keep them in conventional memory with the driver code  
> altogether, but instead prefer them to by dynamic.
>The problem is as follows. If I want to have the tables in files,  
> then loading them in and unloading them from conventional memory will  
> cause several problems, which include slowdowns, risk of instability  
> because of hard-drive access and a big amount of conventional memory  
> still occupied while the tables are in use. I want, therefore, have the  
> tables permanently loaded in high, extended or expanded memory while the  
> driver is running.

I'd disregard EMS (expanded memory), or at least depending on EMS. It's  
supported when installing an EMM386 (+HIMEM) only, and if the user  
switched it on. If you still want to use EMS, write your program so that  
it doesn't need a page frame if running under the correct EMM.

> But this means that the driver will have to do different things to  
> get to the tables depending on whether HIMEM, or EMM386, or both, or  
> none of them are currently there.

Your program can't check for EMM386 or HIMEM, it can only check whether  
XMS or EMS is available.

>I am really not very experienced with high memory, but I understand  
> that, even without HIMEM or EMM386, I can access high memory by setting  
> up real-flat mode.

You're talking about extended memory. High memory is a 64 KiB (- 16 byte)  
area behind the real mode memory (1 MiB). High memory is available in  
normal real mode if the A20 line is switched on. HIMEM provides an  
interface for switching the A20 line.

> Also, if HIMEM only is there, this mode is already available and I can  
> easily access the tables without having to move memory (that is, using  
> 32bit pointers in real mode instead of calling HIMEM functions to copy  
> data).

Not necessarily. HIMEM isn't restricted to this method, and even if your  
HIMEM uses it, you'd still have to set up your own "flat real mode".

>I need help understanding how these two drivers work, as well as what  
> happens in real-flat and virtual-86 modes.

I'd disregard using "flat real mode" at all.

> I also need to know how I can make my interrupt functions flexible  
> enough so that they can work no matter which HIMEM/EMM386 is currently  
> working and, if possible, I would like my functions to also be  
> compatible with protected mode (DPMI) applications calling them, because  
> the functions have to access memory and return pointers

What does your interface look like? Does it return a pointer to the table?  
Then the table has to stay in the memory addressable in real mode, i.e.  
1088 KiB (including the high memory area). Otherwise, not only your driver  
but any application which calls it would have to switch into the "flat  
real mode" on itself.

With XMS (extended memory), your applications either would have to switch  
into "flat real mode" or some sort of protected mode (set up by itself,  
VCPI or DPMI) to access the table directly as well. XMS move requests  
would allow parts of the table (or the full table) to be read into real  
mode memory allocated by the application.

> and therefore, might not work by using real-mode-interrupt calling  
> functions of the DPMI.

Any memory accessible from real mode is accessible by DPMI applications as  
well. Just make sure to retrieve the correct segment and pointer registers  
 from the real mode call structure, and to convert the passed real mode  
segment to a selector correctly.

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

Re: [Freedos-devel] How to get FreeDOS kernel version?

[Christian Masloch]

Int21.33FF returns a pointer to an ASCIZ release string in dx:ax. Try the  
function in a debugger and look at the string; it's format isn't fixed.  
There's no call which returns the numbers but you might try to parse the  
string instead.

Regards,
Christian

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] newer motherboards and [U]EFI, large-sectored drives

[Christian Masloch]

> LARGE SECTOR DRIVES: There is also the issue of large-sectored disks  
> coming after the 2TB drive, if anyone plans on purchasing one of those.   
> by large-sectored I mean drives that have 1024, 2048, 4096 byte sectors.  
> Microsoft has warned of this.  large-sectored drives allow you to use  
> the existing 32-bit-LBA MBR until the UEFI+GPT becomes established as a  
> standard.
> what large sectors affects is disk management utilities such as fdisk  
> and chkdsk and defrag, and partition growing utilities that have  
> hard-coded 512-byte sectors into their code (like I used to).

FreeDOS's kernel also has 512 byte hardcoded as sector size for some  
reason. I don't know about the Int13 low-level stuff yet, but the  
DOS-internal buffer structure is fixed to 512 byte data and DOS's list of  
lists field which specifies the maximal sector size is initialized as 512  
and never used by any code.

Regards,
Christian

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Unable to compile format

[Christian Masloch]

> The lesson to be drawn today: develop in Pascal, since that's not
> case-sensitive, and have a nice system for handling modules (units).
> :p

After one year of Pascal "introduction" in school I still couldn't write  
code easier to read/understand/maintain than my Assembly programs.  
Consider that this is a reason many people prefer other languages over  
Assembly :-P

> Nah, just joking, I know the whole world is a fan of C.

You mean you're just joking, stating that I'm a fan of C? Well, you have  
to know C but I prefer Assembly often :-)

Regards,
Christian

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] Specify RDISK letter

[Christian Masloch]

> I am changing
> RDISK from a .SYS to a .COM file, which will then allow a user
> specified drive letter when loaded thru the AUTOEXEC.BAT file.
> [Not possible in CONFIG.SYS, a "long story" why!].

Actually, with a "bad" hack it is possible to do that. RDISK won't install  
as normal block device driver then anymore but install its drive into DOS  
itself (like when loaded as .COM) and reserve the required memory with a  
dummy character device driver (which contains a name with colon or  
something else so the reserved name doesn't conflict with the filesystem).

Regards,
Christian

--
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Closed: FIXED

[Christian Masloch]

>> > and leaves both (!!!) files present in the directory and empty ...
>> Which both do you mean? It deletes the original,
>> so only the temp file still exists?
>
> YES, but the following rename call apparently recreates the original  
> name,

Yes.

> but without deleting the temp name,

No, the rename call does delete it, but the later (on process termination)  
closing of the handle and SFT returned by 21.5A updates (therefore  
re-creates) the directory entry.

> and both are now empty :-(

I don't know why the original one should be.

> I suspect this behavior could change with recent Bart's large
> SFT&FNODE changes, so the new version will probably need
> many tests anyway and this is one more to pass :-)

An adequate file sharer either won't allow to rename the opened file, or  
update the directory info of the still opened SFT at least so it won't  
re-create the renamed temp file.

Bart's answer is apparently the reason IUP works with MS-DOS, but it's  
still IUP's bug.

Regards,
Christian

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Closed: FIXED

[Christian Masloch]

>> 1. For AH=$5A, EDR-DOS appends slash, FreeDOS doesn't ... what is more
>> valid ???
>
> Appending is valid. RBIL is wrong. MS-DOS 5+ appends it, not only version
> 5.


And just in case someone suspects "evil" usage of DEBUG to disassemble  
MS-DOS: that wasn't even required here. Just test the call on any MS-DOS  
version from 5 up and you can prove they all append the backslash.

Regards,
Christian

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Closed: FIXED

[Christian Masloch]

> 1. For AH=$5A, EDR-DOS appends slash, FreeDOS doesn't ... what is more  
> valid ???

Appending is valid. RBIL is wrong. MS-DOS 5+ appends it, not only version  
5.

> 2. UIP seems to do a very strange thing: it brews a temp file (AH=$5A,
> regrettably not
> visible above, but there was ONE call to it per attempt), throws away
> the handle (!!!), and re-creates the file with $3C [1] ... what is
> supposed to happen ???

Apparently some programmer thought 21.5A only creates the file(name) but  
doesn't open a handle afterwards. Since 21.5A opens the file in  
Compatibility file sharing mode, and 21.3C does the same, that won't raise  
an error even if a file sharer was installed (which I suppose isn't).

> Then it deletes the original file and renames
> the (still opened) temp file to original name [2] ...

Yeah, that's bad. A file sharer possibly generates an error here.

> and leaves both (!!!) files present in the directory and empty ...

Which both do you mean? It deletes the original, so only the temp file  
still exists?

> and additionally a dead cluster chain :-(

I see where the handle returned by 21.5A (whichs SFT, thanks to the lack  
of a file sharer, still contains starting cluster zero) is closed on  
process termination and overwrites the (renamed or whatever) directory  
entry, effectively "forgetting" any allocated cluster chain.

The rename of the temp file *could* take the directory entry of the  
deleted original file as destination but why would it overwrite that one  
with a starting cluster of zero (empty) but not with the temporary  
filename?

Regards,
Christian

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New RxDOS memory subsystem source code

[Christian Masloch]

>> RxDOS is another DOS clone entirely from FreeDOS.
>
> I agree, but *please* send the link to that other list... I would like to
> subscribe :)

This, and that RxDOS isn't so entirely different. First, it's of course  
free now (thanks to Mike!), and second, RxDOS is effectively just a kernel  
plus shell, no complete DOS distribution (what "the FreeDOS project" is).

Regards,
Christian

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New RxDOS memory subsystem source code

[Christian Masloch]

> replying here would be somewhat off topic.

You're saying development of free DOS software is not on topic in the  
"FreeDOS devel" list?

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] New RxDOS memory subsystem source code

[Christian Masloch]

> not yet a fully working kernel.

Am working on RxDOSEXE.ASM right now ;-)

Regards,
Christian

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

[Freedos-devel] New RxDOS memory subsystem source code

[Christian Masloch]

Just linking this item for those of you interested:  


If you want to comment and prefer the mailing list, feel free to add your  
comment as reply here.

Regards,
Christian

--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] DEVLOAD handling of EDR-DOS EDPBs

[Christian Masloch]

> Hi, at the risk of talking too much about EDR DOS...

Are you afraid of different DOS versions? ;-)

>> No, you misunderstood that. He's going to expand the current EDR-DOS  
>> EDPB
>> (call it the [FAT32] DDSC, that's the DR-DOS term "Drive Descriptor") by
>> another 2 bytes, it will be 6 bytes larger than the known EDPB then.
> ...
>> Interestingly, Udo wants to use 4 of the mentioned 6 bytes to improve
>> layout compatibility with MS-DOS, but older version (6.x and 7.00  
>> without
>> FAT32). We had an exhausting discussion about that, but he has a point
>> there. (To understand this, examine how the 16-bit and 32-bit "number of
>> free clusters" fields of the DPB and EDPB overlap.)
>
> As far as I remember, MS uses a 16 bit "low half" field followed
> by a 16 bit "high half" field, which can be seen together as one
> 32 bit field which is truncated after the low half for FAT16...
>
> So I still do not understand why Udo used a 16 bit FAT16 field
> followed by a 32 bit FAT32 field duplicating the data here. Even
> if he tries to put DIFFERENT values into both copies, it would
> only help quite specific FAT16 apps to "understand a bit more
> about that FAT32 drive letter" in specific cases, but would it
> really be worth introducing extra incompatibilities with EDPB?
>
> Adding extra fields AFTER a MS compatible EDPB would have less
> impact on compatibility imho...

Apparently I didn't express it enough, sorry. The new DDSC now uses the  
word dpbFreeClusterCount (that's what I call it), which is the same as the  
low word of the dword edpbFreeClusterCount as you mentioned. The high word  
however isn't used by EDR-DOS (probably set to zero), and the remaining  
EDPB fields are at the addresses you would expect them for MS-DOS and  
DOS-C. After the last EDPB field, the DDSC adds the FAT32 version number  
(one word) and the new field which holds the real number of free clusters  
for FAT32 (one dword). [The order might be exchanged.] This way, the  
overall EDPB layout is implemented but dpbFreeClusterCount can still hold  
a compatibility word value for FAT32-unaware programs even if the drive is  
FAT32. The drawback is that FAT32-aware programs might read a wrong value  
(the FAT16 compatibility value) from edpbFreeClusterCount if they get to  
the DDSC by internal data walking. Udo said he will probably re-write  
EDR-DOS's 21.7302 handler so that it will return an adjusted EDPB  
(edpbFreeClusterCount overwritten with the new DDSC field's value,  
structure shortened to the size of an EDPB) if the buffer size is large  
enough for that one but not large enough for the true DDSC.

>> implement 21.7300 and .7301, too. Your "is still 7300h" check could
>> probably still work, since I'd rather return error 0001h if the
>> subfunction isn't supported. Do you check the Carry Flag properly, too?
>
> Interestingly, MS DOS does NOT use carry in cases where it does
> return AX unchanged when you call a not supported function...
>
> [...]
>
> Phew this starts sounding as esotheric as the attempts of the
> current DEVLOAD to detect DR DOS in the first place... There
> should be some easier way to detect FAT32 and/or DR DOS...
>
> [...]
>
>> I hope there ain't any of these. Udo admits he previously used and
>> believed the list too much, resulting in some previous incompatibilities
>> of EDR-DOS because RBIL in some places wasn't specific enough or wrong
>
> Got some examples?

Yes. The error return register situation, especially for FAT32 functions  
(21.73) and LFN functions (21.71). Originally, DOS versions which didn't  
know function numbers that large would default to the MS-DOS 1.x invalid  
function error code. This means, unaware DOS versions leave CF unchanged  
(!) and set al=00h (!, only ah unchanged). Aware DOS versions (take MS-DOS  
7.10 for FAT32 or MS-DOS 7 with running Windows 4.x for LFN) would provide  
some of the subfunctions, and invalid subfunctions would return the  
appropriate MS-DOS 2.x error code. This means, calling f.e. 21.7142 on  
LFN-capable MS-DOS or Windows versions will result in CF set (!) and  
ax=0001h (!). If new DOS versions provide some but not all 21.71 or 21.73  
subfunctions they might return either the MS-DOS 2.x error code for  
invalid ones or else the MS-DOS 1.x one, for compatibility reasons. If the  
DOS supports FAT32 and most Int21.73 functions, it might return the 2.x  
error code for 21.7300 and .7301. If the DOS doesn't support LFNs  
(natively) but does support some Int21.71 functions (such as .7142) it  
might return the DOS 1.x error code for invalid subfunctions as to show  
unaware programs that there ain't any LFN functions.

RBIL doesn't really document this behaviour (that of MS-DOS 6.x and  
7.00/7.10) correctly and recommends different (more or less working)  
methods to detect whether LFNs or FAT32 are supported. Except from  
checking whether the required 21.71 functions are available, LFN software  
should also call the LFN volume info c

Re: [Freedos-devel] DEVLOAD handling of EDR-DOS EDPBs

[Christian Masloch]

>> - To improve compatibility regarding the EDPB layout, the EDR-DOS EDPB
>> will be expanded to contain another additional 2 bytes. DEVLOAD won't  
>> work
>> with this EDR-DOS version.
>
> I rather had the impression that Udo was willing to make the MS / EDR
> FAT32 DPB size difference smaller than the current 4 bytes? :-). That
> way, adding 2 extra bytes after shaving off 2 others would still keep
> things working with the "general 4 byte safety margin".

No, you misunderstood that. He's going to expand the current EDR-DOS EDPB  
(call it the [FAT32] DDSC, that's the DR-DOS term "Drive Descriptor") by  
another 2 bytes, it will be 6 bytes larger than the known EDPB then.

>> - Other DOS versions might use larger EDPBs
>
> Somewhat unlikely, as MS compatible Ext DPBs for FAT32 contain all
> the fields that a DOS usually needs for FAT32 handling... And of
> course other DOSes might have more focus on MS compatibility, too.

Interestingly, Udo wants to use 4 of the mentioned 6 bytes to improve  
layout compatibility with MS-DOS, but older version (6.x and 7.00 without  
FAT32). We had an exhausting discussion about that, but he has a point  
there. (To understand this, examine how the 16-bit and 32-bit "number of  
free clusters" fields of the DPB and EDPB overlap.)

>> To solve the problem, DEVLOAD could contain code to detect FAT32-capable
>> DOS versions that support Int21.7302 by checking this support...
>
> Current check is using int 21.3306 get true dos version and saying
> fat32 is supported if version is at least 7.01... For comparison,
> WHICHFAT checks for kernel fat32 support via int 21.7300.dl=0.cl=1
> and checking if ax is still 7300 on return which means "no fat32".
> I think / hope this also works if the current drive is not FAT32
> or not even FAT? The dl=0 means current drive.

This method is not very safe, because Udo apparently didn't think 21.7300  
or 21.7301 are required to support FAT32. The purpose of most or all of  
these flags isn't known so we can only guess about it (or disassemble  
MS-DOS and completely rebuilt the code, which is no option). I think,  
since it's all unknown and doesn't seem related to the 'mandatory' drive  
locking for LFNs, that these flags are only there for usage by Windows 4.x  
anyway. This is of course just an educated guess, not a fact.

We didn't talk about this call yet (because I didn't know you used it),  
but I'm independently of the same opinion as Udo and will probably not  
implement 21.7300 and .7301, too. Your "is still 7300h" check could  
probably still work, since I'd rather return error 0001h if the  
subfunction isn't supported. Do you check the Carry Flag properly, too?

> Using int 21.7302 can be problematic as it requires a buffer size
> as input and different DOS versions might need either bigger

That's exactly the trouble we have with EDR-DOS. Fortunately, your program  
can check for an error code of 0018h with Carry Flag set. This error code,  
"Bad request structure", (which was a "critical error" for Int24 returned  
by devices only previously) is used by MS-DOS 7.10+ if the buffer size  
specified in cx is too small. You could even set the buffer size to zero  
and set the drive value to something invalid (to avoid accessing some  
random drive if you don't have to), then determine whether the function  
returned with either ax=0018h, CF set or ax=000Fh, CF set (invalid drive  
error code).

> or
> exactly-right-sized buffers here...

This is a good reason to try the call only with a very large buffer (like  
about 512 byte). Exactly-right-sized buffers could be used to preserve  
compatibility with programs that expect the same EDPB as returned by  
MS-DOS (and therefore provide a buffer not large enough for the larger  
custom DPB), but there's no reason a capable DOS version should deny  
succeeding the function with a buffer which is too large.

>> SETVER-like programs. It could further detect the actual EDPB size using
>> the supported Int21.7302 then. (When using RBIL as reference, note that
>> the buffer description of Int21.7302 is wrong. The word at offset 0 is a
>> returned value only.) This would not require any EDR-DOS check...
>
> See above - some other DOS might have used RBIL as reference...

I hope there ain't any of these. Udo admits he previously used and  
believed the list too much, resulting in some previous incompatibilities  
of EDR-DOS because RBIL in some places wasn't specific enough or plainly  
wrong. RBIL is a fine piece of documentation but you have to question all  
of its content, too. Fortunately I didn't hear of any DOS kernel  
development lately which could have believed RBIL too strictly, since you  
know to avoid this now too.

>> This solution would drop the partial support (only if VERSION= used as
>> explained above) for EDR-DOS 7.01.07 (and currently released 7.01.08
>> WIPs), because this EDR-DOS version returns a smaller, modified EDPB on
>> Int21.7302.
>
> That sounds as if your 

[Freedos-devel] DEVLOAD handling of EDR-DOS EDPBs

[Christian Masloch]

Hi,

the current DEVLOAD version contains a special check for EDR-DOS, to set  
the DPB size to a 4 byte larger value if it's found. (It appends new DPBs  
when loading block devices, and therefore needs to know the size of the  
DPB.) Now, that's a fine thing, to support other DOS versions and all, but  
it has some flaws:

- The EDR-DOS check requires that the first version of (D)CONFIG.SYS  
VERSION=x.y,z.w is set to a value of 6.00, and that the second version is  
larger than 7.00. (The default values of 6.00 and 7.01 confirm to this.)

- To improve compatibility regarding the EDPB layout, the EDR-DOS EDPB  
will be expanded to contain another additional 2 bytes. DEVLOAD won't work  
with this EDR-DOS version.

- Other DOS versions might use larger EDPBs (even larger than 67 bytes),  
too.

To solve the problem, DEVLOAD could contain code to detect FAT32-capable  
DOS versions that support Int21.7302 by checking this support, instead of  
relying on DOS version numbers that can be modified by VERSION= or  
SETVER-like programs. It could further detect the actual EDPB size using  
the supported Int21.7302 then. (When using RBIL as reference, note that  
the buffer description of Int21.7302 is wrong. The word at offset 0 is a  
returned value only.) This would not require any EDR-DOS check. I could  
write this code as a proposal.

This solution would drop the partial support (only if VERSION= used as  
explained above) for EDR-DOS 7.01.07 (and currently released 7.01.08  
WIPs), because this EDR-DOS version returns a smaller, modified EDPB on  
Int21.7302.

EDR-DOS 7.01.06 wouldn't be supported too, because it uses larger DPBs (2  
bytes larger than the DOS-C and MS-DOS EDPB) and actually supports FAT32  
but doesn't provide the Int21.73 functions at all. It however also doesn't  
return OEM value EEh on Int21.3000 so it currently isn't supported either.

DOS versions that don't provide Int21.7302 (usually aren't capable of  
FAT32) but still use a larger DPB than MS-DOS aren't supported by current  
DEVLOAD either unless they confirm to the DOS version values for  
FAT32-capable MS-DOS versions (> 7.00). If this is the case, the proposed  
DEVLOAD version would drop support for these DOS versions.

I discussed this with Eric and later with Udo. While Udo agreed to change  
the EDPB layout of EDR-DOS to more closely match that one of DOS-C and  
MS-DOS, and return the actual EDPB on Int21.7302 instead of a modified  
one, Eric apparently doesn't want to use a SETVER-independant FAT32  
capability check (the problem affects other DOS versions with SETVER, too)  
and an algorithm that safely detects larger EDPBs on FAT32-capable DOS  
versions. What do you think of this? Should DEVLOAD work even if SETVER or  
a similar program (CALLVER, GIVEVER, etc)* is used? Should it allow DOS  
versions with larger, further extended EDPBs?

* After all, the loaded device driver might want a specific DOS version.  
So you'd better expect people to use SETVER on DEVLOAD.

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering

[Christian Masloch]

> You know that open source has advantages,

That's the reason I use it.

> for example FreeDOS
> runs on more modern hardware

Well, decent MS-DOS kernels plus command interpreters also have LBA, FAT32  
and DOSLFN support. (But you're right regarding utilities, the FreeDOS  
ones are often better.)

> and is actively supported.

Is it? I'm still waiting for one of us both to apply the latest patches  
regarding SFTs, file seeks and self-owning PSP termination to the DOS-C  
SVN. Well, anyway: Granted, that's an advantage.

> If you
> try to buy MS DOS instead, they will just tell you that you
> have bad taste and should buy Vista ;-)

So (if you have to) just buy a used version from someone.

> In addition, I have
> no compatibility problems with FreeDOS that would motivate
> me to use another DOS instead.

I don't "use" MS-DOS to actually use it, but to debug it and therefore  
increase the compatibility of FreeDOS, or EDR-DOS, or RxDOS.

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering - Arachne

[Christian Masloch]

> - I am not sure whenever Udo Kuhnt's version uses 16 or 32 bit DPMI but
> it I think it's 16.

The difference isn't that big, anyway. Default code operation size  
changes, but this doesn't require changes to the actual code (even in .ASM  
source files) if the assembler or compiler supports both 16- and 32-bit  
output. The code segment can be larger than 64 KiB, which might be the  
main advantage.

> - 32 bit DPMI would be better.

Not necessarily. Some applications even run dual-mode (RM or 16-bit PM) so  
even 16-bit has it's advantages. The 64 KiB code segment limit is the only  
real disadvantage. (Or are code segments with 16-bit default operation  
size not actually limited to 64 KiB?)

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering

[Christian Masloch]

Hi guys,

EA:
> > Thanks for the warning :-)). Luckily most of the FreeDOS
> > kernel is written in C... One of the things that make it
> > complicated is that it sometimes has to follow long chains
> > of things calling each other because it is documented that
> > MS DOS does it the same way, so for example drivers only
> > work if FreeDOS does the same complicated stuff...

I don't think DOS does anythink too complicated. All layers have a special  
purpose (f.e. CDS for drive redirection, SFT for redirection and device  
handles, etc.) and it isn't that hard to understand all these.

> > A goal reached by illegal means is not really reached in my
> > opinion. If the priority of MS DOS compatibility is higher
> > than the priority of law, stealing MS DOS install disks is
> > a much easier way to reach the goal than stealing sources
> > and putting them or things learned from them into FreeDOS.

If your priority is not to break the law, buy MS-DOS (and/or Win4.x)  
install disks plus license and use (or DEBUG) these legally ;-)

MR:
> Here are very bad news for you. You are violating the law so often in
> your life. There is so many law text concerning you and you can never
> memorize everything and while you are just living you can not have all
> the laws still in back mind, that's impossible.

Still no excuse to break the law when you _know_ you're doing it.

> How can we finally prove that it's illegal or not?

By asking whether we would want someone to "steal" (that is, copy) our  
source code and use it violating the license it was released with. If you  
use leaked Microsoft code then that's as if Microsoft would use  
open-sourced FreeDOS code without providing the source of it or links or  
whatever. (Just as DR-DOS, Inc did for their crappy DR-DOS version 8.00;  
and no one accepted it back then.) Please don't say that Microsoft would  
never do that: I don't care.

> The problem with downloading is that things are virtual and the original
> is still in hands of the original producer. So stealing is probable not
> the right word.

What's the right word, then? I doubt it's "pirating".

> Also again, why do you believe FreeDOS is free of MS-DOS's intellectual
> property? That's impossible as you implemented a "pretty" compatible
> operating system.
>
> What do you think where the Undocumented DOS knowledge has come from?

 From reverse engineering, of course. Some information (f.e. about Novell  
Netware and Novell [DR-]DOS 7.0/6.0, but also from Microsoft) came from  
employees of the associated companies but because they gave these without  
NDA limitations it's allowed to use them, too. Did you read UDOS, anyway?

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering

[Christian Masloch]

> The question whether Masm or Nasm has a larger "community" or is more  
> "widely
> used" is indeed somewhat interesting, but it's interesting because it's a
> common propaganda item which nicely shows that people tend to believe  
> what
> they want to believe.

It's also interesting because JWASM and MASM together are possibly still  
more "widely used" than NASM. That's the reason I explicitly added that  
they have less developers now.

> I realize that you're a bit annoyed, but why? My reply was initiated  
> because I
> felt that someone must take the burden and defend the other side. Isn't  
> that
> just "fair" :)). Please remember, JWasm is an innocent assembler, it  
> cannot
> defend itself.

Lawl. This absolutely made my day! Just keep on defending it.

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering

[Christian Masloch]

> fdpkg requires c:\FDOS?
> how do you maintain a working existing environment
> along side the beta one even following the existing
> structure and using c:\FDOSBETA or something acceptable.

No, it doesn't require this directory name. The directory name is read  
 from the DOSDIR environment variable. It only requires the structure of  
subdirectories found in the %DOSDIR% directory (bin, doc, source, ...).

BTW, why is FDPKG only in the directory of the FreeDOS 1.0 release on  
ibiblio.org? I couldn't find it anywhere else.

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering

[Christian Masloch]

>> If you want to learn about (16-bit) DOS kernel stuff, first get the RBIL
>> (Ralf Brown's Interrupt List) and the source of DOS-C (mostly C) and  
>> Udo's
>> Enhanced DR-DOS kernel (Assembly). (You might as well get the old RxDOS
>> 7.1.5 Assembly sources but oh well.)
>
> ...and the sources for MS-DOS also.

An open source version of MS-DOS? I highly doubt that. I disregard using  
the RxDOS 7.1.5 source not because it's commercial or whatever (it's not,  
7.1.5 is GPL) but because it contains many bugs and even without those it  
won't be as compatible to MS-DOS as the recent versions of all other DOS  
kernels.

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering

[Christian Masloch]

>> As Eric put it, NASM is considered more free than JWASM.
>
> as you probably can see there are also rather "questionable" sentences  
> to find
> in this mailing-list. "Freedom", "Democracy", "Justice", "Fairness", ...  
> are
> commonly regarded as positive terms and because of this they are also  
> favorite
> words to hide other, probably not-so-positive intentions.

So, do you want to accuse me of the "not-so-positive intention" to say  
that JWASM has indeed disadvantages? Of course _I_ think that NASM is  
better. However I also listed other available, free assemblers (which are  
non-existant according to the FreeDOS Spec, aren't they?) and used the  
word "considered" in the comparison. Because it depends on how you  
consider freedom.

> As it is common
> sense to be very cautious when a second-hand car dealer starts to talk  
> about
> "fair prices", it is also a good idea not to believe everything what is  
> posted
> here.

I don't understand how this relates to assemblers. Of course he's free to  
use JWASM instead. You could have posted all the great advantages of JWASM  
over NASM (that you surely know some) instead of this. Like that it's more  
"the original" of x86 Assembly than NASM. Who needs a great manual as  
NASM's, and therefore the possibility to easily learn preprocessor- and  
assembler-specific syntax? (Yes, there might be great MASM manuals or  
books which can be used to write JWASM Assembly. But are they "free", only  
like in "free of charge"?) Or a large community with more than one  
developer, like NASM has? Who cares about that anyway, use the great JWASM  
instead!

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering

[Christian Masloch]

> A (or more then one) virtualizer is a good source for initial developing
> and testing, often an emulator is even more picky about how you
> implement. DOSBox is good for DOS games but many utilities refuse to  
> work.

You can boot a real DOS (f.e. FreeDOS) disk image inside DOSBox which  
makes it usable for development, too.

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Volunteering

[Christian Masloch]

Hi Adam,

> My main interest is programming and a challenge. Occasionally play some  
> old
> games
> that I miss. Bards Tale etc.

Check out Commander Keen ;-)

> Interested in the Kernel and Assembly programming.

If you want to learn something about the DOS kernel and Assembly language  
I could probably tell you a lot (I'm trying to get the old Assembly  
sources of the RxDOS kernel working). You might as well ask Udo Kuhnt  
(from drdosprojects.de, developing another open-source DOS kernel), or the  
DOS-C kernel guys from here (Eric and Tom wrote recently to the mailing  
list).

> See I am way ahead of myself. I have lots of experience programing and
> working on teams. What I don't have is
> dos programming or assembly. I have no clue about what I don't know, am  
> not
> even sure what to ask where to look.
>
> So I am quite content to sit back, take the druggy tasks and do whatever  
> I
> am told. I'll get to the kewl stuff when I learn
> what I am doing.

If learning Assembly, first decide whether to use Microsoft's MASM (or  
compatible, free JWASM), or the free NASM (syntax differs slightly), or  
something else like the free FASM. I know that some versions of NASM's  
manual (f.e. the older .CHM one) contain a list with descriptions of all  
Assembly instructions, which helped me to learn the language itself. As  
Eric put it, NASM is considered more free than JWASM. FASM is also "more  
free" but not used by many people yet.

If you want to learn about (16-bit) DOS kernel stuff, first get the RBIL  
(Ralf Brown's Interrupt List) and the source of DOS-C (mostly C) and Udo's  
Enhanced DR-DOS kernel (Assembly). (You might as well get the old RxDOS  
7.1.5 Assembly sources but oh well.) If you have enough money you may want  
to buy some of the interesting books, especially the second edition of  
"Undocumented DOS" (mainly deals with reverse-engineering MS-DOS and using  
this "undocumented" information, very interesting), "FreeDOS kernel"  
(deals with the source of an early DOS-C & FreeCOM version) and  
"Dissecting DOS" (deals with source of early RxDOS version). Be aware that  
the RBIL and both of the kernel books contain some errors. If something is  
in doubt, check whether MS-DOS works as predicted by the other source. (Of  
course only use paid copies of MS-DOS for this. If you don't have one, a  
recent PC of you running Windows NT (2000, XP, Vista) might contain the  
NTVDM which is similar to MS-DOS. Windows XP is able to create MS-DOS  
bootdisks, too.)

I've discovered a great source of knowledge on how things actually work is  
available by using DEBUG (of course the new FreeDOS DEBUG which has more  
features than the old Microsoft program) to test all kind of stuff in  
Assembly. The source of useful programs like SHSUCDX (MSCDEX replacement)  
and DOSLFN is also interesting (possibly only if you already know the  
basics of DOS programming).

If you've learned all this stuff and found it interesting, there'll be  
plenty of work for you. If not, you might help the DOS-C guys to write  
their FreeDOS kernel in C. Or port Linux software to the DJGPP  
environment. Or do something entirely else :-)

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] building freedos

[Christian Masloch]

>>> Is the 4DOS license okay for Fedora?
>
>> I doubt this. Lucho added some ridiculous
>> crap and limitations to it.
>
> Strong words, do you have examples of changes
> in 4DOS that are unpleasant for you / others?

I'm talking about the license here. Just read what he writes about it on  
the main 4DOS page. Might be I'll have to cry some Chinese phrase from now  
on if I want to download his 4DOS version, too. It's completely ridiculous.

>> Yeah, but ask Japheth whether he wants to keep NoMySo compatibility
>> at all or whether he would use NoMySo once and then develop
>> his software for NASM. I beat the answer is no.
>
> Japheth has grown up with MASM, so he sees no reason
> to get used to NASM, in particular now that he has
> modified WASM into his MASM-compatible JWASM. I do
> like NASM for license, portability and simplicity
> (yet power) but tastes differ and that is okay :-).

So what's the point in claiming that JEMM386 and HIMEMX could be made  
NoMySo-compatible? No one will do that, and even if that turns out to be  
wrong, the one to do it had to do it any time Japheth would break  
compatibility again. (Because there's apparently no reason to stay  
compatible.)

>> So we agree here. But if anyone wants "The FreeDOS Spec"
>> to be used seriously for the FreeDOS project,
>> it should not contradict some of the major programs
>> (other CLI, LFN, DPMI, EMS, XMS) currently available
>
> On one hand - true - on the other hand - for me the
> Spec is mostly a historical document about what were
> the original plans when DOS-C became FreeDOS. Still
> we could also update the spec, if that feels useful.

Well, wasn't it updated to claim NASM and OpenWatcom the main  
assembler/compiler? I'm sure I read the previous version which talked  
about some (cost-)free MASM-compatible assemblers and Turbo C.

Regards,
Christian

--
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] building freedos

[Christian Masloch]

> DOSLFN is probably not free enough for Fedora [...]

I wasn't talking especially about Linux license compatibility here, sorry.

> Is the 4DOS license okay for Fedora?

I doubt this. Lucho added some ridiculous crap and limitations to it.

> Not really written for - Japheth just stopped keeping an eye on the
> NoMySo compatibility of the sources. If you fix that, you can turn
> the sources into NASM compatible and compile those. Not for HX but
> at least for HIMEMX and JEMM386 :-).

Yeah, but ask Japheth whether he wants to keep NoMySo compatibility at all  
or whether he would use NoMySo once and then develop his software for  
NASM. I beat the answer is no.

>> Japheth for this, it just doesn't comply to the current FreeDOS Spec, so
>
> I do not think Japheth is interested in any spec here.

So we agree here. But if anyone wants "The FreeDOS Spec" to be used  
seriously for the FreeDOS project, it should not contradict some of the  
major programs (other CLI, LFN, DPMI, EMS, XMS) currently available (and  
advertised) as part of the project.

>> the Spec should be updated to allow at least all open-source assemblers
>> available for DOS.
>
> Not really... Licenses differ and NASM _is_ more free than JWASM.
> It is also bad to use too many different compilers / assemblers.

Tell that to the MASM crowd. (Who will likely send you back to the NASM  
crowd, though.)

>> A collection of NASM macros to assemble partly adapted source code  
>> doesn't
>> seem possible to me. Even if it is (with some macro hacks) this would
>> probably result in a new assembly language between the existing ones  
>> which
>> neither the JWASM/MASM nor the NASM users would want to write for.
>
> Have a look at NoMySo - a Perl script which turns MASM syntax into
> NASM and is quite sophisticated in doing so. Can probably be adapted
> to work around the differences between MASM and JWASM as well :-p

Just that JWASM is supposed to leave no differences between MASM and the  
former WASM - except new features.

Regards,
Christian

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] building freedos

[Christian Masloch]

> The FreeDOS Spec says:
>
> "Our reference C compiler is OpenWatcom C. (Borland C 3.1 was
> originally chosen as the reference standard because this is the
> compiler used to build the FreeDOS kernel. However, it is preferable
> to use entirely free tools to create FreeDOS.)"
> [...]
> "This does not mean that everyone must use these tools to contribute
> to FreeDOS. That would be counterproductive, as many users may prefer
> other programs. Rather, this means that any C code must be compilable
> on OpenWatcom C, and all Assembly must be assemble-able on NASM. Good
> programming habits such as wise use of #ifdef statements will allow
> you to do this."
>
> http://apps.sourceforge.net/mediawiki/freedos/index.php?title=FreeDOS_Spec#Programming_tools

Assembling anything on NASM is a nice goal (for me, anyway) but isn't yet  
achieved and probably won't ever be. For example, DOSLFN requires TASM  
IDEAL mode and the assembly source files of much advertised 4DOS are  
written for MASM. "FreeDOS" DEBUG recently even got ported back to JWASM  
 from previous NASM source code. JEMM386 (plus assorted JLMs) and HIMEMX  
(which _are_ superior to previous FreeDOS EMM386 and HIMEM) are written  
for JWASM too, just as the HX DOS extender. Of course I don't blame  
Japheth for this, it just doesn't comply to the current FreeDOS Spec, so  
the Spec should be updated to allow at least all open-source assemblers  
available for DOS.

A collection of NASM macros to assemble partly adapted source code doesn't  
seem possible to me. Even if it is (with some macro hacks) this would  
probably result in a new assembly language between the existing ones which  
neither the JWASM/MASM nor the NASM users would want to write for.

Regards,
Christian

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Fwd: [Freedos-kernel] Error compiling ...

[Christian Masloch]

>> You can cast a short to an int, an the conversion in ok, but to cast a
>> short* to an int* will bring in 2 extra bytes and an INVALID POINTER...
>
> no short * and int * are the exact same size in 16-bit compilers (try
> compiling a test program which prints sizeof(int), sizeof(short).  For
> some reason openwatcom thinks it's an error.

I don't know why "unsigned short" to "unsigned int" should be an error if  
they're the same size (probably so code doesn't get unportable due to  
this?), but the new OW 1.8 had changes regarding both _dos_allocmem and  
_dos_getftime. These either caused the warnings or they solved them (if  
they occured in 1.7) but I think the former:

> - The date and time arguments to _dos_getftime() and _dos_setftime()
> are now using 'unsigned int' type instead of 'unsigned short'. This
> change has been made to improve compatibility with other compilers.
>
> - The segment argument used with _dos_allocmem(), _dos_freemem() and
> _dos_setblock() is now unsigned int instead of unsigned short. This
> change was made for compatibility with other compilers.

This is from  


Regards,
Christian

--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] Fantom drives

[Christian Masloch]

>> I have a proposal for the 2038 kernel:
>>
>> What about to add possibility to disable creating the fantom
>> drive B: on systems with only one disk drive (A:) installed?
>
> This feature already exists and is much older than 2035 ;-)
> It is called the DJ mechanism: When you try to access drive
> B: DOS displays a message that you have to put the "other"
> diskette into your A: drive and then press ENTER. When you
> then access A: again, you get the same message, asking you
> to insert the previous diskette again. So you have to play
> diskjockey and DOS lets you use 1 drive for both A: and B:.

I think the request was to remove this "feature" by CONFIG.SYS or compile  
time option. (Quick hack: Disable the B: drive's CDS. Done easily with  
FreeDOS swsubst.)

Regards,
Christian

--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in freedos kernel int 21.1c invalid drive handling?

[Christian Masloch]

> As people might call this to find out whether a
> drive exists, FreeDOS should return the sectors/
> cluster as 255 as expected for invalid drives...

People might do, but it isn't reliable: redirected drives might return  
al=FFh as well.

> The bugfix would make sure AL=255 is returned
> for int 21.1c calls for an invalid drive, but
> for CX and DX and DS:BX I am not sure whether
> it is better to change or not to change them?
> What do the other DOSes or DOSish OSes return?

NTVDM 5.10 MS-DOS returns al=FFh and all other unchanged for invalid  
drives (as expected). Setting ds:bx unconditionally is a DOS-C bug (in  
inthndlr.c) that should be fixed. FatGetDrvData() returns a NULL pointer  
for invalid drives.

>> 4) Other diferencies are in CD/DVD roms and flashdisks.
>
> Yeah, what happens for CD/DVD is kind of random I guess...

I guess it depends on *CDEX, because DOS calls Int2F.110C for redirected  
drives.

Christian

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Re: [Freedos-devel] bug in freedos kernel int 21.1c invalid drive handling?

[Christian Masloch]

> 1) For existing 3,5 floppy disks all give the same (correct) results only
> MSDOS gives wrong Total number of Sectors and Sectors per Cluster

This bug of MS-DOS 7.10 is also documented in RBIL 61.


BTW, I think the other registers should not be changed when al is set to  
FFh regardless of what MS-DOS does.

Christian

--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel