32-bit dos
Paul Edwards
http://sourceforge.net/projects/pdos/
is designed to be a "clean" version of MSDOS. By "clean" I mean
that the interface should have been made portable, so that application
programs could have used the published spec, and when 32-bit
machines became available, it would have been a simple matter of
recompiling the source code and hey presto, you have 32-bit
applications. As such, I am developing both a clean interface, plus
the 16-bit and 32-bit flavours of MSDOS. You can see an example
of the interface below.
My question is as follows. Currently for the 32-bit flavour, I am
using EMX 0.9d under DOS. It produces ".o" files rather than
".obj", and the executables are a.out format. The ".o" files start
off with x'07016400'. I don't know what format that is. I assume
it is neither OMF, nor COFF, nor ELF.
Ideally I want to be able to use both commercially-available and
freeware tools to produce the executables. Because I want
individuals to use free tools while commercial companies should
be able to use commercially-supported tools like MASM and
VisualStudio. I want companies to be able to pick up PDOS and
do whatever the hell they want with it without restriction.
As such, I'm thinking of abandoning EMX 0.9d, but I'm not sure
what to switch to instead. Perhaps Open Watcom. But here's
the catch. The executables I want to create do not need to be
Win32. They're not designed to run under Win32. They're
designed to run under PDOS-32, which I presume is an interface
that no-one else has thought to create. Correct me if I'm wrong,
but check the code below and tell me if someone has a similar
API. ie has someone created an API for all the MSDOS calls,
such that application code just needs to be recompiled with a
32-bit compiler and all the DOS calls still work?
I am not interested in supporting the Win32 API, and I'm not
interested in being able to run 16-bit DOS executables under
32-bit PDOS. Which is why a.out format works perfectly
fine for my purposes. The only glitch is that I want to call my
executables "abc.exe", but when I do that, EMX 0.9d's "ld"
automatically changes it from a.out format to something else,
so instead I need to make my output file "abc" and then rename
it to "abc.exe", which is not very nice. I'm not sure if there's
an option to "ld" to tell it not to do the emxbind, and to just
create an a.out, regardless of the name of the output file. But
I don't know it if there is.
So I can stick with EMX 0.9d and a.out if that is the best
solution, but I am interested to know what other people's
opinions are. What would you advise for tools and executable
format, given that this is (I assume) a unique 32-bit DOS API.
Is the Win32 PE executable format the way to go, even though
I'm using a completely different API? Or should I use
Open Watcom's 32-bit DOS extender format executables
(whatever format that is)? Or should I stick with the current
a.out (can I use tools other than EMX 0.9d to create that or am
I stuck with it?)? I've already written the code to load a.out
files into memory, so obviously that's the easiest for me to
stick with, but I am uneasy about commercial companies having
to use unsupported tools in order to be able to develop
applications for PDOS-32.
Any advice?
Thanks. Paul.
int PosOpenFile(const char *buffer,
int mode,
int *handle)
{
union REGS regsin;
union REGS regsout;
struct SREGS sregs;
regsin.h.ah = 0x3d;
regsin.h.al = (unsigned char)mode;
#ifdef __32BIT__
regsin.d.edx = (unsigned int)buffer;
#else
sregs.ds = FP_SEG(buffer);
regsin.x.dx = FP_OFF(buffer);
#endif
int86x(0x21, ®sin, ®sout, &sregs);
#ifdef __32BIT__
*handle = regsout.d.eax;
#else
*handle = regsout.x.ax;
#endif
return (regsout.x.cflag);
}
drac...@gmail.com
Hi,
I can't help you much because I don't knwo DOS stuff.
Paul Edwards a écrit :
> It produces ".o" files rather than
> ".obj", and the executables are a.out format. The ".o" files start
> off with x'07016400'. I don't know what format that is. I assume
> it is neither OMF, nor COFF, nor ELF.
>
this is a.out binary format. (old binary used by linux and freeBSD)
You have the OMAGIC signature (0x107) wich mean "Code indicating
object file or impure executable"
look at /usr/include/a.out.h if you are a linux user
_
abdel
s_dub...@yahoo.com
#ifndef __I386_A_OUT_H__
#define __I386_A_OUT_H__
struct exec
{
unsigned long a_info; /* Use macros N_MAGIC, etc for access */
unsigned a_text; /* length of text, in bytes */
unsigned a_data; /* length of data, in bytes */
unsigned a_bss; /* length of uninitialized data area for file, in
bytes */
unsigned a_syms; /* length of symbol table data in file, in bytes */
unsigned a_entry; /* start address */
unsigned a_trsize; /* length of relocation info for text, in bytes
*/
unsigned a_drsize; /* length of relocation info for data, in bytes
*/
};
#define N_TRSIZE(a) ((a).a_trsize)
#define N_DRSIZE(a) ((a).a_drsize)
#define N_SYMSIZE(a) ((a).a_syms)
#ifdef __KERNEL__
#define STACK_TOP TASK_SIZE
#endif
#endif /* __A_OUT_GNU_H__ */
Paul, this has .code .data & .bss segment defs., is this what you had
in mind for your Native Mode [protected mode] strategy?
Steve
Ciaran Keating
wrote:
> Is the Win32 PE executable format the way to go, even though
> I'm using a completely different API?
Hi Paul,
I don't see any direct relationship between the executable format and the
operating system API. True, the PE headers can contain fields for the
Windows subsystem, the Windows version, COM+ runtime header, TLS and so
on. But I don't think there's anything specific to the Win32 API. The API
functions themselves are imported as normal DLL imports.
I use PE because it's easy to produce. (I use Visual C++.) And I have no
commercial aspirations.
You might also want to consider what debugger you'll provide with your OS.
Obviously your executable format and your debugger will have to agree on
how to represent debugging symbols.
> I've already written the code to load a.out
> files into memory, so obviously that's the easiest for me to
> stick with, but I am uneasy about commercial companies having
> to use unsupported tools in order to be able to develop
> applications for PDOS-32.
I don't mean to be unkind, but I suppose your OS will be very much a
minority system. Given that, your commercial users will already have
accepted that some things will be a little rough - toolsets, support,
reliability, flexibility, and so on. I doubt that you'll have very many
VB-oriented companies buying your OS!
In short, I don't think your primary criterion for choosing an executable
format should be whether the associated tools are _supported_, but rather
are they widely accepted among your target programmers?
Good luck!
Ciaran
--
Ciaran Keating
Amadán Technologies Pty Ltd
Paul Edwards
drac...@gmail.com wrote:
> Hi,
>
> I can't help you much because I don't knwo DOS stuff.
>
> Paul Edwards a écrit :
>
> > It produces ".o" files rather than
> > ".obj", and the executables are a.out format. The ".o" files start
> > off with x'07016400'. I don't know what format that is. I assume
> > it is neither OMF, nor COFF, nor ELF.
> >
>
> this is a.out binary format. (old binary used by linux and freeBSD)
> You have the OMAGIC signature (0x107) wich mean "Code indicating
> object file or impure executable"
> look at /usr/include/a.out.h if you are a linux user
>
> _
> abdel
> struct exec
> {
> unsigned long a_info; /* Use macros N_MAGIC, etc for access */
> unsigned a_text; /* length of text, in bytes */
> unsigned a_data; /* length of data, in bytes */
> unsigned a_bss; /* length of uninitialized data area for file, in
> bytes */
> unsigned a_syms; /* length of symbol table data in file, in bytes */
> unsigned a_entry; /* start address */
> unsigned a_trsize; /* length of relocation info for text, in bytes
> */
> unsigned a_drsize; /* length of relocation info for data, in bytes
> */
> };
The ".o" files do not have this structure. They are therefore not a.out
format, they are something else.
> Paul, this has .code .data & .bss segment defs., is this what you had
> in mind for your Native Mode [protected mode] strategy?
Yes, that is what I have already implemented. I already handle
those segments, initializing the BSS etc. Now I am trying to
decide whether to abandon the a.out format altogether and use
a different executable format, that still has the functionality I
need.
BFN. Paul.
susan.ar...@ntlworld.com
Is not FreeDos32 similar to your API ?.
My OS is a 32bit pmode dos like OS, but i chose to get a way from old
Dos functions, as this is too restrictive, if you give codes good
function and good doc, this is better for coders, than trying to
recompile something code to run under 16bit.
But good luck.
Regards Dex
DexOS Batteries not included, Some assembly required.
Alexei A. Frounze
> The operating system I have been working on, PDOS, available at:
> http://sourceforge.net/projects/pdos/
>
> is designed to be a "clean" version of MSDOS. By "clean" I mean
> that the interface should have been made portable, so that application
> programs could have used the published spec, and when 32-bit
> machines became available, it would have been a simple matter of
> recompiling the source code and hey presto, you have 32-bit
> applications. As such, I am developing both a clean interface, plus
> the 16-bit and 32-bit flavours of MSDOS. You can see an example
> of the interface below.
How will you treat the DOS functions that only take/return segments, not
segment:offset pair? Among such there're mem allocation and program
execution. Also, PSP isn't just an ID in DOS. So, how clean is the
implementation going to be here?
> My question is as follows. Currently for the 32-bit flavour, I am
> using EMX 0.9d under DOS. It produces ".o" files rather than
> ".obj", and the executables are a.out format. The ".o" files start
> off with x'07016400'. I don't know what format that is. I assume
> it is neither OMF, nor COFF, nor ELF.
>
> Ideally I want to be able to use both commercially-available and
> freeware tools to produce the executables. Because I want
> individuals to use free tools while commercial companies should
> be able to use commercially-supported tools like MASM and
> VisualStudio. I want companies to be able to pick up PDOS and
> do whatever the hell they want with it without restriction.
One can download Visual C++ Express and use for free. One interesting twist
is that you can download MASM too, but the installer for it does two things:
2nd -- requires Visual C++ Express and 1st -- it's EULA or whatever you see
when you start the setup says:
----8<----
1. INSTALLATION AND USE RIGHTS. You may install and use one copy of the
software on your device to design, develop and test your programs for
non-commercial purposes. You may not use the software to develop programs
you either intend to distribute for a fee or use to maintain your own
business or IT systems.
----8<----
I don't know if it's possible to replace MASM by something else. Anyways,
you or someone could try make use of this MS compiler.
Figure out exactly what you need from the executable format. I bet you don't
need much for DOS applications, whether they are 16-bit or 32-bit. If that
is true, you can either transform/postprocess whatever the linker emits to
make it in this format of yours or just accept the linker's output as is and
do processing at load time. I don't see much of a problem here.
Alex
Rod Pemberton
"Paul Edwards" <kerr...@nosppaam.w3.to> wrote in message
news:457be5a6$0$1036$61c6...@un-2park-reader-01.sydney.pipenetworks.com.au...
> The operating system I have been working on, PDOS, available at:
> http://sourceforge.net/projects/pdos/
>
> is designed to be a "clean" version of MSDOS. By "clean" I mean
> that the interface should have been made portable, so that application
> programs could have used the published spec, and when 32-bit
> machines became available, it would have been a simple matter of
> recompiling the source code and hey presto, you have 32-bit
> applications. As such, I am developing both a clean interface, plus
> the 16-bit and 32-bit flavours of MSDOS. You can see an example
> of the interface below.
>
> freeware tools to produce the executables. Because I want
> individuals to use free tools while commercial companies should
> be able to use commercially-supported tools like MASM and
> VisualStudio. I want companies to be able to pick up PDOS and
> do whatever the hell they want with it without restriction.
>
> As such, I'm thinking of abandoning EMX 0.9d, but I'm not sure
> what to switch to instead. Perhaps Open Watcom.
The personal DOS applications that I've written run under both DJGPP (32-bit
DOS) and OW (16-bit & 32-bit DOS). I know that someone (Alexei Frounze was
that you?) said he was considering dropping DJGPP due to lack of future
development. But, that shouldn't affect a 32-bit DOS OS. In fact, it might
improve it since no future bugs will be introduced from the compiler tools.
> But here's
> the catch. The executables I want to create do not need to be
> Win32. They're not designed to run under Win32.
You can do that with DJGPP or OW for 16-bit DOS. DJGPP uses a DPMI host to
run it's 32-bit code. OW 1) runs pure 16-bit code or 2) uses a DPMI host
with DOS-Extender to run 32-bit code.
e.g.,
for 16-bit OW:
wcl/l=dos myccode.c
for 32-bit OW (DPMI host with DOS-Extender):
wcl386/l=dos4g myccode.c
for 32-bit DJGPP (DPMI host):
gcc -o myccode.exe myccode.c
> They're
> designed to run under PDOS-32, which I presume is an interface
> that no-one else has thought to create. Correct me if I'm wrong,
> but check the code below and tell me if someone has a similar
> API. ie has someone created an API for all the MSDOS calls,
> such that application code just needs to be recompiled with a
> 32-bit compiler and all the DOS calls still work?
>
I'm not sure if someone has wrappers for the entire set of DOS calls. Most
of the library calls used by DJGPP and OW are fairly simple wrappers. But,
I doubt anyone has wrappers which select between a RM 16-bit and a PM 32-bit
call.
Essentially what you've created for the 32-bit PM calls is called a
DOS-Extender (i.e., it's pure, since there is no DPMI host). The DPMI host
adds 32-bit memory management on top of 16-bit DOS. A DOS-Extender provides
a 32-bit API for 16-bit DOS or BIOS calls.
Sometimes the DOS extender has it's own complete 32-bit routines, but
usually they just use the DPMI host to do a PM to RM call back to the 16-bit
DOS or BIOS function. I looked at your code a while back, and I think
you've already done this or something similar. But, you could look at all
the DOS-Extenders written in C which are open source. That could be alot of
work just to find the code since I've found 33 available DPMI
hosts/DOS-Extenders for DOS.
Someone suggested Freedos-32, that might one be one way to get 32-bit DOS
functions, but it's not PD code.
My personal OS, which is way behind compared to yours or Freedos-32, is
essentially having to do the same thing: recreate 32-bit C routines for all
DOS and BIOS code called by the C libraries. If I counted correctly, OW
v1.3 uses about 120 DOS and BIOS calls and DJGPP uses 170 DOS and BIOS
calls. My original goal wasn't an OS: I wanted a DPMI host/DOS Extender
that worked for both DJGPP and OW. I was hoping to merge PMODEDJ and
PMODEW, but the sources weren't available for PMODEW at the time. My x86
assembly has improved much since then, so I probably could do that today.
Back to my OS, since I don't really want to write all those functions, I've
been considering either V86 mode support or 16-bit x86 emulation.
I'd probably attempt to get the code working for DPMI and/or DOS-Extender.
The format is a 16-bit DOS executable whose startup code loads the DPMI host
and/or DOS-Extender. It then switches to PM, runs the 32-bit program, which
calls the DPMI host and/or DOS-Extender as necessary. The DPMI host and/or
DOS-Extender handle the 32-bit PM to 16-bit RM and 16-bit RM to 32-bit PM
switches as needed for the DOS or BIOS calls. Actually, they usually use
V86 mode instead of 16-bit RM...
> int PosOpenFile(const char *buffer,
> int mode,
> int *handle)
> {
> union REGS regsin;
> union REGS regsout;
> struct SREGS sregs;
>
> regsin.h.ah = 0x3d;
> regsin.h.al = (unsigned char)mode;
> #ifdef __32BIT__
> regsin.d.edx = (unsigned int)buffer;
> #else
> sregs.ds = FP_SEG(buffer);
> regsin.x.dx = FP_OFF(buffer);
> #endif
> int86x(0x21, ®sin, ®sout, &sregs);
> #ifdef __32BIT__
> *handle = regsout.d.eax;
> #else
> *handle = regsout.x.ax;
> #endif
> return (regsout.x.cflag);
> }
How many of the functions you use are as simple as the function above? If
all of them are very similar, you could write a more generic calls. I'd
suspect that most of the file access calls are probably about the same.
How many other DOS or BIOS calls do you use?
Rod Pemberton
Paul Edwards
> I'm not sure if someone has wrappers for the entire set of DOS calls. Most
> of the library calls used by DJGPP and OW are fairly simple wrappers. But,
> I doubt anyone has wrappers which select between a RM 16-bit and a PM 32-bit
> call.
My wrappers select between the two at compile time of course,
not runtime. It seems like a fairly obvious approach.
> Essentially what you've created for the 32-bit PM calls is called a
> DOS-Extender (i.e., it's pure, since there is no DPMI host).
Ok.
> The DPMI host
> adds 32-bit memory management on top of 16-bit DOS. A DOS-Extender provides
> a 32-bit API for 16-bit DOS or BIOS calls.
>
> Sometimes the DOS extender has it's own complete 32-bit routines, but
> usually they just use the DPMI host to do a PM to RM call back to the 16-bit
> DOS or BIOS function. I looked at your code a while back, and I think
> you've already done this or something similar.
Well, the operating system is pure 32-bit, but it does revert to
doing 16-bit BIOS calls. I don't actually care about that, as it
is transparent to the applications.
> But, you could look at all
> the DOS-Extenders written in C which are open source. That could be alot of
> work just to find the code since I've found 33 available DPMI
> hosts/DOS-Extenders for DOS.
>
> Someone suggested Freedos-32, that might one be one way to get 32-bit DOS
> functions, but it's not PD code.
Well you've looked at them. Did they create an API similar to mine?
I can change my API if some sort of consensus has already emerged.
> My personal OS, which is way behind compared to yours or Freedos-32, is
> essentially having to do the same thing: recreate 32-bit C routines for all
> DOS and BIOS code called by the C libraries.
Any reason why you didn't take my OS as a starting point? It is
deliberately PD so that no-one has to reinvent the wheel regardless
of their intended destination.
> If I counted correctly, OW
> v1.3 uses about 120 DOS and BIOS calls and DJGPP uses 170 DOS and BIOS
> calls. My original goal wasn't an OS: I wanted a DPMI host/DOS Extender
> that worked for both DJGPP and OW. I was hoping to merge PMODEDJ and
> PMODEW, but the sources weren't available for PMODEW at the time. My x86
> assembly has improved much since then, so I probably could do that today.
> Back to my OS, since I don't really want to write all those functions, I've
> been considering either V86 mode support or 16-bit x86 emulation.
Not sure what you're talking about there. Can you elaborate on what
the problem is and what you're planning on doing to solve it?
> I'd probably attempt to get the code working for DPMI and/or DOS-Extender.
> The format is a 16-bit DOS executable whose startup code loads the DPMI host
> and/or DOS-Extender. It then switches to PM, runs the 32-bit program, which
> calls the DPMI host and/or DOS-Extender as necessary. The DPMI host and/or
> DOS-Extender handle the 32-bit PM to 16-bit RM and 16-bit RM to 32-bit PM
> switches as needed for the DOS or BIOS calls. Actually, they usually use
> V86 mode instead of 16-bit RM...
But I don't have any of this. I'm not using DPMI. I'm not using
16-bit DOS. The 32-bit OS doesn't have the ability to interpret
16-bit executables. And I don't have a desire to add that
capability either. I'm not interested in 16-bit executables. I'm
only after source-code compatibility with a clean DOS API.
> > int PosOpenFile(const char *buffer,
> > int mode,
> > int *handle)
> > {
> > union REGS regsin;
> > union REGS regsout;
> > struct SREGS sregs;
> How many of the functions you use are as simple as the function above? If
They are all that simple. Because the DOS API is simple.
> all of them are very similar, you could write a more generic calls.
I'm not trying to rewrite the existing DOS API, I'm just trying
to provide a C front-end to it, as should have been done right
from the beginning, so that 16-bit DOS apps magically and
automatically became 32-bit, simply by a recompile. I am
just correcting this oversight, so that I can move on with my
life. :-)
> I'd
> suspect that most of the file access calls are probably about the same.
> How many other DOS or BIOS calls do you use?
I have written 37 DOS calls and 29 BIOS calls. Which is enough
to handle Borland-compiled text-processing executables. That I
have tested, anyway.
Thanks for your reply BTW. I still haven't mastered 16-bit DOS,
so don't assume I know anything in particular.
BFN. Paul.
Alexei A. Frounze
> The personal DOS applications that I've written run under both DJGPP
> (32-bit DOS) and OW (16-bit & 32-bit DOS). I know that someone
> (Alexei Frounze was that you?) said he was considering dropping DJGPP
> due to lack of future development. But, that shouldn't affect a
> 32-bit DOS OS. In fact, it might improve it since no future bugs
> will be introduced from the compiler tools.
It's not the lack of future development, but rather a lack of backward
compatibility in the OS that will prevent me and others from 2 things:
running applications built with DJGPP and running DJGPP toolset itself. It
seems to me that I can easily create a simple wrapper based on DirectX to
make my GUI demo work under Windows. That will of course won't exercise all
of the VGA code, but I can live with that since that code is stable.
> Back to my OS, since I
> don't really want to write all those functions, I've been considering
> either V86 mode support or 16-bit x86 emulation.
I'm going to create a v86 server process to take care of disk I/O and
graphics modes. That will let me move ahead without studying every
applicable doc on disk programming and writing my drivers for that. Yet,
AFAIK there're SCSI disks that are accessible through the BIOS, while if you
nuke BIOS, it will be harder to write a special driver for those beasts.
Alex
Rod Pemberton
> "Rod Pemberton" <do_no...@bitfoad.cmm> wrote in message
news:1165838...@dscnews2.dcccd.edu...
I'm going to answer your questions in reverse order. Second, I'll use PDOS
to refer to your DOS and use MS-DOS to refer to the operation of a gold
standard DOS.
> I have written 37 DOS calls and 29 BIOS calls. Which is enough
> to handle Borland-compiled text-processing executables. That I
> have tested, anyway.
>
That's what my OS is missing: MS-DOS and BIOS functions for PM. Are those
completely new 32-bit only code, new 16-bit only code, or callbacks to
16-bit BIOS/PDOS code? IIRC, your 32-bit PDOS code uses callbacks to 16-bit
PDOS code, which implements the 16-bit PDOS functions using 16-bit BIOS
functions. So, you have a mix of 32-bit and 16-bit code?
> > > int PosOpenFile(const char *buffer,
> > > int mode,
> > > int *handle)
> > > {
> > > union REGS regsin;
> > > union REGS regsout;
> > > struct SREGS sregs;
>
> > How many of the functions you use are as simple as the function above?
>
> They are all that simple. Because the DOS API is simple.
>
> > If all of them are very similar, you could write a more generic calls.
>
> I'm not trying to rewrite the existing DOS API, I'm just trying
> to provide a C front-end to it, as should have been done right
> from the beginning, so that 16-bit DOS apps magically and
> automatically became 32-bit, simply by a recompile.
>
Sorry, I was thinking about the assembly interface to PM 32-bit int 0nnh
interrupts, not a C interface around them. The assembly interface may have
a de-facto DOS-Extender standard. I'm unsure of any completely standardized
method for C compilers. Freedos-32 may have decided on one, but I think
their code might be DJGPP specific.
> magically and automatically
What I know is how BIOS (and MS-DOS) calls are made in OW and DJGPP. I
don't know about Borland C or Turbo C or MSVC 1.52...
a) Your code is using int86x(), like a 16-bit OW to call BIOS (or MS-DOS)
functions. (The 16-bit OW code has to be radically modified to be compiled
as 32-bit OW.)
b) 32-bit OW typically calls 16-bit BIOS (or MS-DOS) functions using
int386x() which calls the DPMI host, but can also directly call any
supported DOS-Extender functions (which reduces the amount of C code).
c) 32-bit DJGPP typically calls 16-bit BIOS (or MS-DOS) functions using
__dpmi_int() which calls the DPMI host.
This code here shows three methods:
http://www.openwatcom.org/index.php/Accessing_the_Harddisk_using_LBA_under_DPMI
For b) or c) to be plug-n-play, I think the intermediate functionality of
the DPMI host would need to be implemented. In PDOS, I believe you've
implemented some/most of the core functionality of a DPMI host:
trap interrupt in 32-bit mode
copy registers <1Mb
switch to RM
call BIOS
copy registers to PM
switch back to PM
return from interrupt
You just haven't implemented specific DPMI functions (which are
standardized: DPMI 0.9 or 1.0) or DOS-Extender functions (which aren't
standardized as far as I know. There may be a de-facto standard, but since
I don't use extended functions, I'd have to take a look...).
> > I'd probably attempt to get the code working for DPMI and/or
> > DOS-Extender. The format is a 16-bit DOS executable whose
> > startup code loads the DPMI host and/or DOS-Extender. It then
> > switches to PM, runs the 32-bit program, which calls the DPMI host
> > and/or DOS-Extender as necessary. The DPMI host and/or
> > DOS-Extender handle the 32-bit PM to 16-bit RM and 16-bit RM to
> > 32-bit PM switches as needed for the DOS or BIOS calls. Actually,
> > they usually use V86 mode instead of 16-bit RM...
>
> But I don't have any of this. I'm not using DPMI. I'm not using
> 16-bit DOS.
But, you are using 16-bit BIOS and 16-bit PDOS. To do so, you've
(re)implemented about 1/4 of the functionality provide by a DPMI
host/DOS-Extender (the callbacks). So, the 32-bit only portion of PDOS,
could be made to run on MS-DOS using DPMI, if you wanted...(unnecessary).
> > If I counted correctly, OW
> > v1.3 uses about 120 DOS and BIOS calls and DJGPP uses 170 DOS and BIOS
> > calls. My original goal wasn't an OS: I wanted a DPMI host/DOS Extender
> > that worked for both DJGPP and OW. I was hoping to merge PMODEDJ and
> > PMODEW, but the sources weren't available for PMODEW at the time. My
> > x86 assembly has improved much since then, so I probably could do that
> > today. Back to my OS, since I don't really want to write all those
> > functions, I've been considering either V86 mode support or 16-bit x86
> > emulation.
>
> Not sure what you're talking about there. Can you elaborate on what
> the problem is and what you're planning on doing to solve it?
>
The problem is my OS is 32-bit only currently (no 16-bit at all) and I'm
wanting DPMI programs (which are mostly 32-bit, but use 16-bit MS-DOS and
BIOS calls) compiled by DJGPP and OW to run on it.
In more depth, parts of the C compiler and libraries are dependent and
independent on the OS. The main functionality of C compilers are free from
OS calls (DOS/BIOS): constants, variables, flow control (if, while,
procedures,setjmp,etc.) arithmetic, pointers.
Also, a portion of the C libraries are free from OS calls:
is*,to*,mem*,str*,sprintf,scanf
But, some portions of the C libraries are dependent on the OS.
a) fileio: open, close, read, write, fopen, fclose, fread, fwrite, printf,
fprintf, fscanf, directory functions
b) memory manager and heap: malloc, alloc, calloc, free, auto variables
So, if I want to be able to execute OW or DJGPP DPMI applications (mostly
32-bit) for my OS (32-bit only) which use MS-DOS and BIOS calls, there must
be replacements for those calls. If I decide to go with v86 (16-bit) mode
support, I can use 16-bit callbacks like your OS or a DOS-Extender to make
BIOS calls. If I leave 16-bit MS-DOS resident (since my OS can start from
MS-DOS), say using the MS-DOS SDA save/restore functions, before starting my
OS, I could also make MS-DOS calls. If I boot without MS-DOS, then I'll
have to implement the MS-DOS functions used by the C libraries in 32-bit
code. And, if I choose to not use 16-bit cpu modes at all, then I'll also
need to write 32-bit BIOS functions too. (I haven't decided yet...long term
I'd prefer no 16-bit dependencies or cpu mode dependencies.).
> > My personal OS, which is way behind compared to yours or Freedos-32, is
> > essentially having to do the same thing: recreate 32-bit C routines for
> > all DOS and BIOS code called by the C libraries.
>
> Any reason why you didn't take my OS as a starting point? It is
> deliberately PD so that no-one has to reinvent the wheel regardless
> of their intended destination.
>
I stumbled across your webpage by accident while archiving Public Domain
code (wanting to build a C library which was also when I stumbled across Mr.
Baute's work.). This was after I had already been working on my OS for some
time. Then your webpage, which just had links to a bunch of files without
much explanation, disappeared for a long time. After some aggressive
searches, I found the sourceforge webpage, which (still) didn't have much
information on the two projects (PDOS,PDPCLIB), didn't have any anonymous
non-email method to communicate with you, and didn't have any packaged files
to download. Although one could've downloaded the files individually by
CVS... I then looked into separating out just the 32-bit code from the
16-bit code, not realizing at first that you are doing 16-bit RM callbacks
for the OS functions... i.e., without the 16-bit callbacks, I'm in same
boat as my OS: no low level PM functions. I continued anyway, but couldn't
figure out how to separate some of the passed 16-bit startup parameters from
the 32-bit code (or I got confused...). So, since I was wanting a pure
32-bit DOS, I went back to my OS and waited on Freedos32 (still waiting).
> > But, you could look at all
> > the DOS-Extenders written in C which are open source. That could be
> > alot of work just to find the code since I've found 33 available DPMI
> > hosts/DOS-Extenders for DOS.
> >
> > Someone suggested Freedos-32, that might one be one way to get 32-bit
> > DOS functions, but it's not PD code.
>
> Well you've looked at them. Did they create an API similar to mine?
> I can change my API if some sort of consensus has already emerged.
>
Actually, I haven't really. Their OS is radically different from what I'm
doing. They've made some strong steps forward, but I question some of their
original design decisions:
Why didn't they do a port of DJGPP first, instead of using OSLib?
Why didn't they port the C parts of Freedos?
I was just hoping they'd complete sometime before me, but I don't think
that's going to happen either. I suspect they may have run into the after
effects of their design choices. I haven't seen a release in a long time.
Rod Pemberton
Rod Pemberton
"Alexei A. Frounze" <ale...@chat.ru> wrote in message
news:N8SdnV6iQ7MmhePY...@comcast.com...
> Rod Pemberton wrote:
> > The personal DOS applications that I've written run under both DJGPP
> > (32-bit DOS) and OW (16-bit & 32-bit DOS). I know that someone
> > (Alexei Frounze was that you?) said he was considering dropping DJGPP
> > due to lack of future development. But, that shouldn't affect a
> > 32-bit DOS OS. In fact, it might improve it since no future bugs
> > will be introduced from the compiler tools.
>
> It's not the lack of future development, but rather a lack of backward
> compatibility in the OS that will prevent me and others from 2 things:
> running applications built with DJGPP and running DJGPP toolset itself. It
> seems to me that I can easily create a simple wrapper based on DirectX to
> make my GUI demo work under Windows. That will of course won't exercise
all
> of the VGA code, but I can live with that since that code is stable.
>
> > Back to my OS, since I
> > don't really want to write all those functions, I've been considering
> > either V86 mode support or 16-bit x86 emulation.
>
> I'm going to create a v86 server process to take care of disk I/O and
> graphics modes. That will let me move ahead without studying every
> applicable doc on disk programming and writing my drivers for that.
"without studying every applicable doc on disk programming" #$% $%#
Did I hear a hint of frustration? :-)
I thought you were going 64-bit and couldn't v86...? AEMU?
> Yet,
> AFAIK there're SCSI disks that are accessible through the BIOS, while if
you
> nuke BIOS, it will be harder to write a special driver for those beasts.
>
Rod Pemberton
Alexei A. Frounze
I want to get something done and move on.
> I thought you were going 64-bit and couldn't v86...? AEMU?
I'm not yet going 64-bit. There's enough work in 32-bit mode too. But I'm
guessing I'll be running a 64-bit version of Windows in which v86 won't work
and if I go straight to 64-bit mode in my OS I'll also have to write extra
VM environment to make real-mode code run despite being in 64-bit mode. And
that will be a more serious and bigger chunk of code than to a 32-bit v86
monitor.
Alex
kerravon
My news server missed half of the messages in this thread! :-(
> Paul Edwards wrote:
> > The operating system I have been working on, PDOS, available at:
> > http://sourceforge.net/projects/pdos/
> >
> > is designed to be a "clean" version of MSDOS. By "clean" I mean
> > that the interface should have been made portable, so that application
> > programs could have used the published spec, and when 32-bit
> > machines became available, it would have been a simple matter of
> > recompiling the source code and hey presto, you have 32-bit
> > applications. As such, I am developing both a clean interface, plus
> > the 16-bit and 32-bit flavours of MSDOS. You can see an example
> > of the interface below.
>
> How will you treat the DOS functions that only take/return segments, not
> segment:offset pair? Among such there're mem allocation and program
> execution.
The clean interface to them is an API that returns a full pointer, not
just the segment. While the interrupt only returns a segment, an
offset of 0 is added by the API so that the caller gets a full pointer.
See the code at the bottom.
> Also, PSP isn't just an ID in DOS. So, how clean is the
> implementation going to be here?
The PSP is the same in the 32-bit version. ie same restriction on
command line parameter length.
> > My question is as follows. Currently for the 32-bit flavour, I am
> > using EMX 0.9d under DOS. It produces ".o" files rather than
> > ".obj", and the executables are a.out format. The ".o" files start
> > off with x'07016400'. I don't know what format that is. I assume
> > it is neither OMF, nor COFF, nor ELF.
> >
> > Ideally I want to be able to use both commercially-available and
> > freeware tools to produce the executables. Because I want
> > individuals to use free tools while commercial companies should
> > be able to use commercially-supported tools like MASM and
> > VisualStudio. I want companies to be able to pick up PDOS and
> > do whatever the hell they want with it without restriction.
>
> One can download Visual C++ Express and use for free. One interesting twist
> is that you can download MASM too, but the installer for it does two things:
> 2nd -- requires Visual C++ Express
It doesn't if you go "vcpp5 /c". You can get the ml.exe executable
that way.
> Figure out exactly what you need from the executable format. I bet you don't
> need much for DOS applications, whether they are 16-bit or 32-bit. If that
> is true, you can either transform/postprocess whatever the linker emits to
> make it in this format of yours or just accept the linker's output as is and
> do processing at load time. I don't see much of a problem here.
I want to accept the linker's output. What I don't know is which
linker
to accept the output from! ie which executable format to choose.
BFN. Paul.
void *PosAllocMem(unsigned int size)
{
union REGS regsin;
union REGS regsout;
regsin.h.ah = 0x48;
#ifdef __32BIT__
regsin.d.ebx = size;
#else
regsin.x.bx = size;
regsin.x.bx >>= 4;
if ((size % 16) != 0)
{
regsin.x.bx++;
}
#endif
int86(0x21, ®sin, ®sout);
#ifdef __32BIT__
if (regsout.x.cflag)
{
regsout.d.eax = 0;
}
return ((void *)regsout.d.eax);
#else
if (regsout.x.cflag)
{
regsout.x.ax = 0;
}
return (MK_FP(regsout.x.ax, 0));
#endif
}
kerravon
Ciaran Keating wrote:
> You might also want to consider what debugger you'll provide with your OS.
> Obviously your executable format and your debugger will have to agree on
> how to represent debugging symbols.
Good point. I hadn't thought that far ahead. None of the debuggers
will work because 32-bit DOS is not an existing operating system.
But I guess the process of creating a debugger will be the same
regardless of whether it is EMX 0.9d that is ported using a.out format
or Open Watcom 1.6 using the Win32 PE format.
> > I've already written the code to load a.out
> > files into memory, so obviously that's the easiest for me to
> > stick with, but I am uneasy about commercial companies having
> > to use unsupported tools in order to be able to develop
> > applications for PDOS-32.
>
> I don't mean to be unkind, but I suppose your OS will be very much a
> minority system. Given that, your commercial users will already have
> accepted that some things will be a little rough - toolsets, support,
> reliability, flexibility, and so on. I doubt that you'll have very many
> VB-oriented companies buying your OS!
Well the intention is not to buy it from me. The intention is for
people
to buy a DERIVED version of my OS from a company.
> In short, I don't think your primary criterion for choosing an executable
> format should be whether the associated tools are _supported_, but rather
> are they widely accepted among your target programmers?
The target is a company that wants an operating system for their
own purpose. I expect them to want to use supported software.
Obviously they need to maintain the OS by themselves, because
it is basically their product. But they shouldn't be expected to
maintain the tools as well. Commercial companies like to use
supported software.
BFN. Paul.
Ciaran Keating
> Ciaran Keating wrote:
>> You might also want to consider what debugger you'll provide with your
>> OS.
>> Obviously your executable format and your debugger will have to agree on
>> how to represent debugging symbols.
>
> Good point. I hadn't thought that far ahead. None of the debuggers
> will work because 32-bit DOS is not an existing operating system.
> But I guess the process of creating a debugger will be the same
> regardless of whether it is EMX 0.9d that is ported using a.out format
> or Open Watcom 1.6 using the Win32 PE format.
Yeah, I reckon you're right. I'm not sure whether I'm looking forward to
writing my debugger or not! I might never get that far.
>> I doubt that you'll have very many
>> VB-oriented companies buying your OS!
>
> Well the intention is not to buy it from me. The intention is for
> people
> to buy a DERIVED version of my OS from a company.
Ah, I see.
> The target is a company that wants an operating system for their
> own purpose. I expect them to want to use supported software.
> Obviously they need to maintain the OS by themselves, because
> it is basically their product. But they shouldn't be expected to
> maintain the tools as well. Commercial companies like to use
> supported software.
So you'll sell your OS to an OS development company or something like
that? And they'll sell the (modified or packaged) OS to businesses? Just
curious... what are your differentiators? Why wouldn't the end customer
just buy Windows or Linux? Perhaps because yours will be less expensive?
Or support less powerful hardware? Or provide an upgrade path for older
MS-DOS programs?
Cheers,
kerravon
Rod Pemberton wrote:
> > I have written 37 DOS calls and 29 BIOS calls. Which is enough
> > to handle Borland-compiled text-processing executables. That I
> > have tested, anyway.
>
> That's what my OS is missing: MS-DOS and BIOS functions for PM. Are those
> completely new 32-bit only code, new 16-bit only code, or callbacks to
> 16-bit BIOS/PDOS code? IIRC, your 32-bit PDOS code uses callbacks to 16-bit
> PDOS code, which implements the 16-bit PDOS functions using 16-bit BIOS
> functions. So, you have a mix of 32-bit and 16-bit code?
No, you have misunderstood what PDOS is. It comes in two flavours,
PDOS-16 and PDOS-32. Everything has two versions (via conditional
compilation). The API comes in both a 16-bit and 32-bit flavour, and
the OS comes in both a 16-bit and 32-bit flavour.
PDOS-32 does NOT call PDOS-16. PDOS-32 is a pure 32-bit executable.
It does make use of 16-bit BIOS calls, but there is no 16-bit OS
anywhere.
It neither uses nor supports 16-bit. I only want to maintain source
code
compatibility, not executable compatibility.
> > I'm not trying to rewrite the existing DOS API, I'm just trying
> > to provide a C front-end to it, as should have been done right
> > from the beginning, so that 16-bit DOS apps magically and
> > automatically became 32-bit, simply by a recompile.
>
> Sorry, I was thinking about the assembly interface to PM 32-bit int 0nnh
> interrupts, not a C interface around them. The assembly interface may have
> a de-facto DOS-Extender standard.
Ok, well that's the bit that's the least important, as it is hidden
behind the API. But I guess I should switch to the de-facto
DOS-Extender standard for assembler if it exists.
> I'm unsure of any completely standardized
> method for C compilers. Freedos-32 may have decided on one, but I think
> their code might be DJGPP specific.
Ok.
> b) 32-bit OW typically calls 16-bit BIOS (or MS-DOS) functions using
> int386x() which calls the DPMI host, but can also directly call any
> supported DOS-Extender functions (which reduces the amount of C code).
I wonder if I should be calling int386x instead of int86x too? I
just made a 32-bit version of int86x, which took 32-bit registers.
> c) 32-bit DJGPP typically calls 16-bit BIOS (or MS-DOS) functions using
> __dpmi_int() which calls the DPMI host.
Ok.
> For b) or c) to be plug-n-play, I think the intermediate functionality of
> the DPMI host would need to be implemented. In PDOS, I believe you've
> implemented some/most of the core functionality of a DPMI host:
I'm not totally sure what a DPMI host is, but I don't think I have done
that, as I believe that is a 32-bit memory management for a 16-bit
OS. I have not done that. I have created a pure 32-bit OS.
Conditional
compilation will create a pure 16-bit OS from the same source code.
Both OS's make use of the 16-bit BIOS though, but that is all internal
and thus can be replaced by direct hardware calls if wanted.
> trap interrupt in 32-bit mode
> copy registers <1Mb
> switch to RM
> call BIOS
> copy registers to PM
> switch back to PM
> return from interrupt
Yes, I have done that. But only because you said call BIOS, rather
than call 16-bit OS function. I have implemented the OS by making
use of the BIOS rather than directly manipulating the hardware.
> You just haven't implemented specific DPMI functions (which are
> standardized: DPMI 0.9 or 1.0) or DOS-Extender functions (which aren't
> standardized as far as I know. There may be a de-facto standard, but since
> I don't use extended functions, I'd have to take a look...).
Ok.
> > > I'd probably attempt to get the code working for DPMI and/or
> > > DOS-Extender. The format is a 16-bit DOS executable whose
> > > startup code loads the DPMI host and/or DOS-Extender. It then
> > > switches to PM, runs the 32-bit program, which calls the DPMI host
> > > and/or DOS-Extender as necessary. The DPMI host and/or
> > > DOS-Extender handle the 32-bit PM to 16-bit RM and 16-bit RM to
> > > 32-bit PM switches as needed for the DOS or BIOS calls. Actually,
> > > they usually use V86 mode instead of 16-bit RM...
> >
> > But I don't have any of this. I'm not using DPMI. I'm not using
> > 16-bit DOS.
>
> But, you are using 16-bit BIOS and 16-bit PDOS.
No, only the former.
> To do so, you've
> (re)implemented about 1/4 of the functionality provide by a DPMI
> host/DOS-Extender (the callbacks). So, the 32-bit only portion of PDOS,
> could be made to run on MS-DOS using DPMI, if you wanted...(unnecessary).
It is outside the concept of PDOS-32 to try to get it to run under
MS-DOS.
> So, if I want to be able to execute OW or DJGPP DPMI applications (mostly
> 32-bit) for my OS (32-bit only) which use MS-DOS and BIOS calls, there must
> be replacements for those calls.
Isn't this conceptually wrong from the start? DOS-extended programs
are designed to run under a 16-bit OS, not 32-bit. Why didn't you
write
a 16-bit OS instead? I don't see that a 32-bit OS actually has
anything
to do!
> I stumbled across your webpage by accident while archiving Public Domain
> code (wanting to build a C library which was also when I stumbled across Mr.
> Baute's work.). This was after I had already been working on my OS for some
> time. Then your webpage, which just had links to a bunch of files without
> much explanation, disappeared for a long time.
It never disappeared, just changed locations. It used to be on
freespace virgin, then it was on exetel (still is), then it was also
put into sourceforge.
> After some aggressive
> searches, I found the sourceforge webpage, which (still) didn't have much
> information on the two projects (PDOS,PDPCLIB), didn't have any anonymous
> non-email method to communicate with you, and didn't have any packaged files
> to download.
Ok, the packaged files were on exetel, not sourceforge, as I didn't
know
how to package files on sourceforge. I do now, so they are available
now.
Can you tell me why you didn't want to use email for communication?
There are forums on sourceforge, but I wouldn't have seen the posts
there as my sourceforge email was incorrect and I didn't know about
that, and I didn't know the forums even existed anyway.
> Although one could've downloaded the files individually by
> CVS...
That is actually what I expected people to do - but not individually.
CVS allows you to extract the entire source tree.
> I then looked into separating out just the 32-bit code from the
> 16-bit code, not realizing at first that you are doing 16-bit RM callbacks
> for the OS functions...
I'm not.
Also, what do you need to separate out the code for? It's done via
conditional compilation. The 16-bit stuff automatically disappears!
> i.e., without the 16-bit callbacks, I'm in same
> boat as my OS: no low level PM functions. I continued anyway, but couldn't
> figure out how to separate some of the passed 16-bit startup parameters from
> the 32-bit code (or I got confused...).
Not sure what you're talking about there.
> So, since I was wanting a pure
> 32-bit DOS, I went back to my OS and waited on Freedos32 (still waiting).
Well while you're waiting, I hope you can tell me what you expect
a 32-bit DOS to look like!
BFN. Paul.
susan.ar...@ntlworld.com
I think a 32bit DOS should be more like this http://www.dex4u.com/
As thats what DexOS is.
kerravon
> > Well while you're waiting, I hope you can tell me what you expect
> > a 32-bit DOS to look like!
>
> As thats what DexOS is.
I've browsed the website, but the FAQ didn't answer what I wanted
to know. Which is:
What is the API for C programs to use?
What format do the application executables need to be in?
BFN. Paul.
s_dub...@yahoo.com
Alexei A. Frounze wrote:
> > I thought you were going 64-bit and couldn't v86...? AEMU?
>
> I'm not yet going 64-bit. There's enough work in 32-bit mode too. But I'm
> guessing I'll be running a 64-bit version of Windows in which v86 won't work
> and if I go straight to 64-bit mode in my OS I'll also have to write extra
> VM environment to make real-mode code run despite being in 64-bit mode. And
> that will be a more serious and bigger chunk of code than to a 32-bit v86
> monitor.
>
> Alex
Do the 64-bit motherboard bios' use EFI, extensible firmware interface?
Alexei A. Frounze
> Alexei A. Frounze wrote:
>
> My news server missed half of the messages in this thread! :-(
>
>> Paul Edwards wrote:
>>> The operating system I have been working on, PDOS, available at:
>>> http://sourceforge.net/projects/pdos/
>>>
>>> is designed to be a "clean" version of MSDOS. By "clean" I mean
>>> that the interface should have been made portable, so that
>>> application programs could have used the published spec, and when
>>> 32-bit
>>> machines became available, it would have been a simple matter of
>>> recompiling the source code and hey presto, you have 32-bit
>>> applications. As such, I am developing both a clean interface, plus
>>> the 16-bit and 32-bit flavours of MSDOS. You can see an example
>>> of the interface below.
>>
>> How will you treat the DOS functions that only take/return segments,
>> not segment:offset pair? Among such there're mem allocation and
>> program execution.
>
> The clean interface to them is an API that returns a full pointer, not
> just the segment. While the interrupt only returns a segment, an
> offset of 0 is added by the API so that the caller gets a full
> pointer. See the code at the bottom.
That's the problem. If your system is entirely 32-bit and doesn't bother
about segments (which is probably what you intend), then you have to
redefine the meaning of the segment value in this case and/or redefine the
DOS API for this functionality because otherwise this offset of 0 or segment
value is meaningless. So, your implementation of DOS may be not very clean,
not everywhere.
Alex
Alexei A. Frounze
So far I've only seen regular BIOSes. Maybe there are some (non-Mac) that
have it, but I'm unaware.
Alex
kerravon
> > The clean interface to them is an API that returns a full pointer, not
> > just the segment. While the interrupt only returns a segment, an
> > offset of 0 is added by the API so that the caller gets a full
> > pointer. See the code at the bottom.
>
> That's the problem. If your system is entirely 32-bit and doesn't bother
> about segments (which is probably what you intend),
Correct.
> then you have to
> redefine the meaning of the segment value in this case and/or redefine the
> DOS API for this functionality
There doesn't exist a clean DOS API for C programs. That's the
problem. I am defining one as a starting point.
> because otherwise this offset of 0 or segment
> value is meaningless. So, your implementation of DOS may be not very clean,
> not everywhere.
What do you mean? My DOS API for C programs is clean. It doesn't
return a segment, it returns a pointer. C programs thus port to 16-bit
DOS or 32-bit DOS with a simple recompile. The assembler API for
16-bit DOS is unchanged, but the C API is clean.
BFN. Paul.
Alexei A. Frounze
I just had an impression that in your system it would be OK for an
application to do int 21h directly.
Alex
stu
kerravon wrote:> BFN. Paul.
you keep harping on about your API. who cares about that. Its C, give
me the std c lib,
you know, fopen, fread, etc I dont care what fopen does underneath as
long as it works.
I dont care about your API. If I am writing apps on pdos-32, the api
does not matter.
you talk about just recompiling the app, so if its written in C, all
you need is the c library.
we dont need your api details.
when I read this thread it seems like you are confusing the internal
implementation (ax=3D02
int21 for file open with the external interface (c library fopen).
-stu
Rod Pemberton
"kerravon" <kerr...@w3.to> wrote in message
news:1165963763....@f1g2000cwa.googlegroups.com...
>
> Rod Pemberton wrote:
> > > I have written 37 DOS calls and 29 BIOS calls. Which is enough
> > > to handle Borland-compiled text-processing executables. That I
> > > have tested, anyway.
> >
> > That's what my OS is missing: MS-DOS and BIOS functions for PM. Are
those
> > completely new 32-bit only code, new 16-bit only code, or callbacks to
> > 16-bit BIOS/PDOS code? IIRC, your 32-bit PDOS code uses callbacks to
16-bit
> > PDOS code, which implements the 16-bit PDOS functions using 16-bit BIOS
> > functions. So, you have a mix of 32-bit and 16-bit code?
>
> No, you have misunderstood what PDOS is. It comes in two flavours,
> PDOS-16 and PDOS-32. Everything has two versions (via conditional
> compilation). The API comes in both a 16-bit and 32-bit flavour, and
> the OS comes in both a 16-bit and 32-bit flavour.
>
> PDOS-32 does NOT call PDOS-16. PDOS-32 is a pure 32-bit executable.
> It does make use of 16-bit BIOS calls, but there is no 16-bit OS
> anywhere.
> It neither uses nor supports 16-bit. I only want to maintain source
> code
> compatibility, not executable compatibility.
>
Yes, I definately have misunderstood. I didn't see or recognize that while
working on the code. Maybe that was why I was confused in my attempts to
separate the 32-bit stuff. New section for a FAQ?
So, the 32-bit version only needs 32-bit replacements for the BIOS calls.
How many BIOS calls does the 32-bit version use (still 29) ?
> > But, you are using 16-bit BIOS and 16-bit PDOS.
>
> No, only the former.
>
I'm clear now.
> > So, if I want to be able to execute OW or DJGPP DPMI applications
(mostly
> > 32-bit) for my OS (32-bit only) which use MS-DOS and BIOS calls, there
must
> > be replacements for those calls.
>
> Isn't this conceptually wrong from the start?
Yes. Everything for my OS has been done backwards. Have you ever heard of
another OS starting development from DOS and not a bootloader? I can only
think of one: Windows98.
I didn't want an OS. I wanted a DPMI host that was common to OW and DJGPP.
But, in my preliminary development of a common DPMI host, I realized that
the easiest way to get a common DMPI host was to replace the compiler
specific DPMI host with another one _after_ the program loaded. In the
process of doing that, I realized I could develop an OS using standard DPMI
.exe's. It mean that I didn't have to develop a compiler tool chain
specific to my OS, or a kernel library, special OS tools, etc.
> DOS-extended programs
> are designed to run under a 16-bit OS, not 32-bit. Why didn't you
> write
> a 16-bit OS instead? I don't see that a 32-bit OS actually has
> anything
> to do!
>
I think I answered most above, but a pure 32-bit OS intended to run DPMI
applications has to:
1) recreate 16-bit DOS calls used by the C library in 32-bit
2) recreate 16-bit BIOS calls used by the C library in 32-bit
3) recreate 32-bit DOS-Extender calls used by the C library
4) recreate 16-bit or 32-bit DPMI calls used by the C library as 32-bit, if
not
Most of the code in a DPMI application is 32-bit code. So, I guess you
could say my OS has two requirements:
1) use DPMI applications from DOS compilers as the native executable format
2) create a pure 32-bit OS which can run those executables
Now that I understand your OS better, it appears that you've skipped this
process, so you probably can't use the native executable formats of your
compiler. You must be having a problem generating executable formats which
are compatible with your OS. Yes, it appears that you do:
> Which is why a.out format works perfectly
> fine for my purposes. The only glitch is that I want to call my
> executables "abc.exe", but when I do that, EMX 0.9d's "ld"
> automatically changes it from a.out format to something else,
> so instead I need to make my output file "abc" and then rename
> it to "abc.exe", which is not very nice. I'm not sure if there's
> an option to "ld" to tell it not to do the emxbind, and to just
> create an a.out, regardless of the name of the output file. But
> I don't know it if there is.
I'd try to see which default outputs could be converted to A.OUT or perhaps
you need to switch to another format like ELF.
For DJGPP, if you don't specify abc.exe, but abc, it will output both abc
and abc.exe. abc is unstubbed and in an DJGPP COFF format. DJGPP's LD
should output A.OUT, DJGPP COFF, and ELF. Also, DJGPP has OBJCOPY.exe which
converts DJGPP COFF to A.OUT-I386. I'm not sure if A.OUT-I386 is the
standard A.OUT or not.
For OW, I haven't seen anything that indicates OW supports A.OUT. OW
produces OMF. These can be linked into .EXE or ELF or many others. One can
unstub OW DOS executables using DOS32A's SB.EXE unbind utility. You might
then look for tools to convert different linker formats to A.OUT. Or, you
could try to output ELF and use ELF2AOUT.
There is also a version of DJGPP (not on Delorie's site) which creates ELF.
ELF may be another format you could use.
Some tools:
objcopy (DJGPP)
emxomf (EMX)
elf2aout
elf2ecoff
coff2omf (Digital Mars)
ar (some Windows ports) COFF,OMF
> Can you tell me why you didn't want to use email for communication?
I don't have an email account (and don't intend to setup one anytime soon).
Sourceforge has aggressive spam filters which confirms accounts from the
posting host (i.e., I can't post from my PC, I must go through my ISP or an
open server...) Baute has a no-login or anonymous http form to post to his
forum. And, I don't need email, just an open newserver and newsreader to
read/post to NNTP.
> > Although one could've downloaded the files individually by
> > CVS...
>
> That is actually what I expected people to do - but not individually.
> CVS allows you to extract the entire source tree.
>
Okay, I missed that... Is that through the web-browse or only through the
CVS application?
> > I then looked into separating out just the 32-bit code from the
> > 16-bit code, not realizing at first that you are doing 16-bit RM
callbacks
> > for the OS functions...
>
> I'm not.
>
> Also, what do you need to separate out the code for? It's done via
> conditional compilation. The 16-bit stuff automatically disappears!
>
I didn't understand it was working that way...
Rod Pemberton
kerravon
Alexei A. Frounze wrote:
> > What do you mean? My DOS API for C programs is clean. It doesn't
> > return a segment, it returns a pointer. C programs thus port to
> > 16-bit DOS or 32-bit DOS with a simple recompile. The assembler API
> > for 16-bit DOS is unchanged, but the C API is clean.
>
> I just had an impression that in your system it would be OK for an
> application to do int 21h directly.
Not at all. There should have been a C API wrapper created around the
DOS OS calls, right from the start. The same as exist for Win32 and
OS/2.
I am correcting that oversight as a first step towards creating a
32-bit
version of DOS. It is an obvious thing to do, which is why I asked if
there
was an existing standard DOS C API.
BFN. Paul.
kerravon
stu wrote:
> kerravon wrote:
> > susan.ar...@ntlworld.com wrote:
> > What is the API for C programs to use?
> >
> > BFN. Paul.
>
> you keep harping on about your API. who cares about that. Its C, give
> me the std c lib,
> you know, fopen, fread, etc I dont care what fopen does underneath as
> long as it works.
The standard C library using fopen etc provides only a skerrick of the
functionality of DOS. If someone wants to write a sophisticated
application
instead of a command line tool, they need to use the DOS API, or even
directly manipulate the hardware. Are you saying that Windows and OS/2
shouldn't have provided the enormous API either, that everyone should
be writing command line tools that purely process text files? Not even
allow directory traversal tools?
> I dont care about your API. If I am writing apps on pdos-32, the api
> does not matter.
It matters a lot!
> you talk about just recompiling the app, so if its written in C, all
> you need is the c library.
> we dont need your api details.
No, you need a standardized way of invoking the DOS functionality.
You also need a standardized way of manipulating the hardware -
that will work regardless of whether you are in 32-bit or 16-bit mode.
I have created macros to do that. E.g. rather than hardcoding the
video address as
char *addr = 0xb8000000;
you instead go:
char *addr = ABSADDR(0xb8000);
In 32-bit mode, ABSADDR adds a "correction" provided by the CRT
and PDOS-32. In 16-bit mode it will convert it into a 0xb8000000.
> when I read this thread it seems like you are confusing the internal
> implementation (ax=3D02
> int21 for file open with the external interface (c library fopen).
No, ultimately fopen() needs to call the DOS function. And for 32-bit
DOS the way the interrupt is used is different from 16-bit DOS. So
DOS needs to export a standard API, which works in both 16-bit and
32-bit. In the same way that OS/2 and Windows have exported APIs.
BFN. Paul.
kerravon
Rod Pemberton wrote:
> Yes, I definately have misunderstood. I didn't see or recognize that while
> working on the code. Maybe that was why I was confused in my attempts to
> separate the 32-bit stuff. New section for a FAQ?
I have updated the readme.txt to make that point clear.
> So, the 32-bit version only needs 32-bit replacements for the BIOS calls.
> How many BIOS calls does the 32-bit version use (still 29) ?
Correct. Not sure about "use" though. I have probably implemented
some
BIOS calls even though they weren't required. Some DOS calls as well.
The intention is to implement them all, regardless of whether I
personally
use them. Apps may require them.
> I think I answered most above, but a pure 32-bit OS intended to run DPMI
> applications has to:
> 1) recreate 16-bit DOS calls used by the C library in 32-bit
> 2) recreate 16-bit BIOS calls used by the C library in 32-bit
> 3) recreate 32-bit DOS-Extender calls used by the C library
> 4) recreate 16-bit or 32-bit DPMI calls used by the C library as 32-bit, if
> not
If you are running DOS-extended executables, then the DOS extender
comes as part of the executable. Or is your intention to bypass that
extender?
> Most of the code in a DPMI application is 32-bit code. So, I guess you
> could say my OS has two requirements:
> 1) use DPMI applications from DOS compilers as the native executable format
> 2) create a pure 32-bit OS which can run those executables
>
> Now that I understand your OS better, it appears that you've skipped this
> process, so you probably can't use the native executable formats of your
> compiler. You must be having a problem generating executable formats which
> are compatible with your OS. Yes, it appears that you do:
:-)
> > Which is why a.out format works perfectly
> > fine for my purposes. The only glitch is that I want to call my
> > executables "abc.exe", but when I do that, EMX 0.9d's "ld"
> > automatically changes it from a.out format to something else,
> > so instead I need to make my output file "abc" and then rename
> > it to "abc.exe", which is not very nice. I'm not sure if there's
> > an option to "ld" to tell it not to do the emxbind, and to just
> > create an a.out, regardless of the name of the output file. But
> > I don't know it if there is.
>
> I'd try to see which default outputs could be converted to A.OUT
Pardon?
> or perhaps you need to switch to another format like ELF.
I don't want to switch formats just for the sake of switching. Is
there
a reason to choose ELF over a.out?
> For DJGPP, if you don't specify abc.exe, but abc, it will output both abc
> and abc.exe. abc is unstubbed and in an DJGPP COFF format. DJGPP's LD
> should output A.OUT, DJGPP COFF, and ELF.
Ok, good to know I can replace EMX with DJGPP then.
> Also, DJGPP has OBJCOPY.exe which
> converts DJGPP COFF to A.OUT-I386. I'm not sure if A.OUT-I386 is the
> standard A.OUT or not.
Ok.
> For OW, I haven't seen anything that indicates OW supports A.OUT. OW
> produces OMF. These can be linked into .EXE or ELF or many others. One can
> unstub OW DOS executables using DOS32A's SB.EXE unbind utility.
And what do you get when you unstub them?
> You might
> then look for tools to convert different linker formats to A.OUT. Or, you
> could try to output ELF and use ELF2AOUT.
Ok, so that means with this tool, people can even compile using OW,
output ELF, then use ELF2OUT. That makes 3 compilers that can
produce PDOS-32 executables.
> There is also a version of DJGPP (not on Delorie's site) which creates ELF.
You said above that DJGPP produced ELF. I think your second
statement is the one which is correct, as I read in the FAQ of
DJGPP that it is a common request for ELF but he doesn't want
to do it.
> > Can you tell me why you didn't want to use email for communication?
>
> I don't have an email account (and don't intend to setup one anytime soon).
Is there a reason for this?! How do you survive without email?!
> > > Although one could've downloaded the files individually by
> > > CVS...
> >
> > That is actually what I expected people to do - but not individually.
> > CVS allows you to extract the entire source tree.
>
> Okay, I missed that... Is that through the web-browse or only through the
> CVS application?
Through the CVS application.
Honestly, CVS is an INCREDIBLE productivity tool. If you don't know
what
a 3-way diff is, encapsulated with branches, you should really look
into it.
BFN. Paul.
stu
kerravon wrote:
> The standard C library using fopen etc provides only a skerrick of the
> functionality of DOS. If someone wants to write a sophisticated
> application
> instead of a command line tool, they need to use the DOS API, or even
aaah so your going to provide a graphical api now as well?
> directly manipulate the hardware. Are you saying that Windows and OS/2
> shouldn't have provided the enormous API either, that everyone should
> be writing command line tools that purely process text files? Not even
> allow directory traversal tools?
err you are comparing the full win32 library to dos? dos is minimalist.
some funcs for files, some for dirs some for mallocs.. really it has
SFA
in it. its not multi user, its not multitasking, its nothing. dos is
nothing but
slightly extended bios calls.
>
> > I dont care about your API. If I am writing apps on pdos-32, the api
> > does not matter.
>
> It matters a lot!
>
> > you talk about just recompiling the app, so if its written in C, all
> > you need is the c library.
> > we dont need your api details.
>
> No, you need a standardized way of invoking the DOS functionality.
>
> char *addr = 0xb8000000;
>
> you instead go:
>
> char *addr = ABSADDR(0xb8000);
this has nothing to do with DOS. If I am buying a 32bit OS for my
embedded doorbell, I'm going to program it to the specs of my hardware
and I wont be thinking.. mm I have a 32bit memory address, I need
to wrap it in a macro just in case I end up buying a 16bit OS.
thats why MK_SEG + MK_FP macros are provided by 16bit c compilers....
> In 32-bit mode, ABSADDR adds a "correction" provided by the CRT
> and PDOS-32. In 16-bit mode it will convert it into a 0xb8000000.
>
> > when I read this thread it seems like you are confusing the internal
> > implementation (ax=3D02
> > int21 for file open with the external interface (c library fopen).
>
> No, ultimately fopen() needs to call the DOS function. And for 32-bit
> DOS the way the interrupt is used is different from 16-bit DOS. So
> DOS needs to export a standard API, which works in both 16-bit and
> 32-bit. In the same way that OS/2 and Windows have exported APIs.
>
err you still dont get it. it does not matter how fopen calls the api,
either via callgate, interrupt or jump table. as long as it opens the
file it can have a 100% different interface, and it will. real mode is
not
protected mode. segments are not selectors. different word sizes make a
HUGE difference.
i cant read 8gb of data in pdos-16, your not going to be able to
keep the same api and have apps 100% compatible from pdos-16 to
pdos-32.
I think you need to stop trying to beleive 16bit and 32bit are
equivocal
and interchangeable.
nobody is going to program apps/interfaces for pdos in assembler. they
will
use C or C++ or D or python or whatever. it does not matter what your
api
looks like. wrap it with a C interface and be done with it.
-stu
stu
kerravon wrote:
> > For OW, I haven't seen anything that indicates OW supports A.OUT. OW
> > produces OMF. These can be linked into .EXE or ELF or many others. One can
> > unstub OW DOS executables using DOS32A's SB.EXE unbind utility.
>
> And what do you get when you unstub them?
linear executables "LE"
>
> Ok, so that means with this tool, people can even compile using OW,
> output ELF, then use ELF2OUT. That makes 3 compilers that can
> produce PDOS-32 executables.
objcopy and its ilk are poor development tools.
> > There is also a version of DJGPP (not on Delorie's site) which creates ELF.
>
> You said above that DJGPP produced ELF. I think your second
> statement is the one which is correct, as I read in the FAQ of
> DJGPP that it is a common request for ELF but he doesn't want
> to do it.
djgpp is just a poor port of gcc, you can recompile binutils to output
10000 formats.
djgpp binutils are just compiled to putput djgpp coff
if you want your environment to be self hosting you will need a 16bit
compiler
which djgpp is not. OW does have 16bit compilers.
-stu
Rod Pemberton
>
> > I think I answered most above, but a pure 32-bit OS intended to run DPMI
> > applications has to:
> > 1) recreate 16-bit DOS calls used by the C library in 32-bit
> > 2) recreate 16-bit BIOS calls used by the C library in 32-bit
> > 3) recreate 32-bit DOS-Extender calls used by the C library
> > 4) recreate 16-bit or 32-bit DPMI calls used by the C library as 32-bit,
if
> > not
>
> If you are running DOS-extended executables, then the DOS extender
> comes as part of the executable. Or is your intention to bypass that
> extender?
>
Yes. Bypass the 16-bit startup, the 16 or 32-bit DPMI, the DOS-Extender.
Run the main 32-bit program backfilling in the missing DOS and BIOS calls as
part of the OS. .exe compatibility, whereas I think you're after source
compatibilty.
> I don't want to switch formats just for the sake of switching. Is
> there
> a reason to choose ELF over a.out?
>
Do the compilers you want to generate a.out actually generate a.out?
> > For OW, I haven't seen anything that indicates OW supports A.OUT. OW
> > produces OMF. These can be linked into .EXE or ELF or many others. One
can
> > unstub OW DOS executables using DOS32A's SB.EXE unbind utility.
>
> And what do you get when you unstub them?
>
> > You might
> > then look for tools to convert different linker formats to A.OUT. Or,
you
> > could try to output ELF and use ELF2AOUT.
>
> Ok, so that means with this tool, people can even compile using OW,
> output ELF, then use ELF2OUT. That makes 3 compilers that can
> produce PDOS-32 executables.
>
ELF2AOUT is not part of OW. You'd probably have to port it.
> > There is also a version of DJGPP (not on Delorie's site) which creates
ELF.
>
> You said above that DJGPP produced ELF. I think your second
> statement is the one which is correct, as I read in the FAQ of
> DJGPP that it is a common request for ELF but he doesn't want
> to do it.
>
I've seen a few ways:
1) Daniel Borca's ELF version of DJGPP, 2nd link:
http://www.geocities.com/dborca/
2) DJGPP ELF binutils:
http://membres.lycos.fr/placr/
3) another ELF binutils:
http://elfbinutils.narod.ru/
4) Some FAQ which says one just needs to download newer versions of some
packages and recompile that I can't seem to find at the moment...
> How do you survive without email?!
>
You're talking to me, aren't you? :-)
Q3,nntp,html forms, some direct email from PC - not everyone blocks, that's
all I need. If you need to contact some "expert" related to: Linux,
assembly, DOS, etc. Just use Google Groups advanced search to see what
newsgroup they also post to... Most of the "experts" are familiar with
newsgroups (maybe even Fidonet ;-) , but post '96 internet users use http
based forums.
> Honestly, CVS is an INCREDIBLE productivity tool. If you don't know
> what
> a 3-way diff is, encapsulated with branches, you should really look
> into it.
>
Ugh, learning curve. They probably have more advanced versions of CVS
today. But, the CVS program I dl'd a few years ago was a command line
@#$^ing nightmare...
I know most people who've used CVS and Perforce seem to prefer Perforce. I
personally just prefer a way to get the current version of everything as
.zip, .tgz, .bz2 or .rpm via an http link (too old school?).
Rod Pemberton
Rod Pemberton
"stu" <yakum...@gmail.com> wrote in message
news:1166056907.7...@f1g2000cwa.googlegroups.com...
>
> djgpp is just a poor port of gcc,
No, DJGPP uses it's own DOS specific C libraries.
> if you want your environment to be self hosting you will need a 16bit
> compiler
> which djgpp is not. OW does have 16bit compilers.
>
Um, yes it is. It's just not completely automated:
1) http://www.delorie.com/djgpp/16bit/
2) GAS directives: .code16, .data16, .code16gcc
3) http://devpit.org/wiki/Compiler_Options_for_Creating_Odd_Binaries
Rod Pemberton
Alexei A. Frounze
...
> The standard C library using fopen etc provides only a skerrick of the
> functionality of DOS. If someone wants to write a sophisticated
> application
> instead of a command line tool, they need to use the DOS API, or even
> directly manipulate the hardware. Are you saying that Windows and
> OS/2 shouldn't have provided the enormous API either, that everyone
> should be writing command line tools that purely process text files?
> Not even allow directory traversal tools?
Oddly enough, DOS' findfirst/findnext functionality is harder to use than
POSIX opendir()/readdir()/etc. To traverse the directories recursively (or
at least two levels deep) using the DOS functions you need to manually move
that special structure that's used for searching by DOS...
Alex
kerravon
stu wrote:
> kerravon wrote:
> > The standard C library using fopen etc provides only a skerrick of the
> > functionality of DOS. If someone wants to write a sophisticated
> > application
> > instead of a command line tool, they need to use the DOS API, or even
>
> aaah so your going to provide a graphical api now as well?
Only if DOS supports such calls.
> > directly manipulate the hardware. Are you saying that Windows and OS/2
> > shouldn't have provided the enormous API either, that everyone should
> > be writing command line tools that purely process text files? Not even
> > allow directory traversal tools?
>
> err you are comparing the full win32 library to dos? dos is minimalist.
> some funcs for files, some for dirs some for mallocs.. really it has
> SFA
> in it. its not multi user, its not multitasking, its nothing. dos is
> nothing but
> slightly extended bios calls.
Which is what we need a C interface to.
> > No, you need a standardized way of invoking the DOS functionality.
> >
> > char *addr = 0xb8000000;
> >
> > you instead go:
> >
> > char *addr = ABSADDR(0xb8000);
>
> this has nothing to do with DOS. If I am buying a 32bit OS for my
> embedded doorbell, I'm going to program it to the specs of my hardware
> and I wont be thinking.. mm I have a 32bit memory address, I need
> to wrap it in a macro just in case I end up buying a 16bit OS.
And what if you buy a 16-bit embedded doorbell, and then later
on decide to make it 32-bit?
> thats why MK_SEG + MK_FP macros are provided by 16bit c compilers....
They should have provided ABSADDR.
> > No, ultimately fopen() needs to call the DOS function. And for 32-bit
> > DOS the way the interrupt is used is different from 16-bit DOS. So
> > DOS needs to export a standard API, which works in both 16-bit and
> > 32-bit. In the same way that OS/2 and Windows have exported APIs.
>
> err you still dont get it. it does not matter how fopen calls the api,
> either via callgate, interrupt or jump table. as long as it opens the
> file it can have a 100% different interface, and it will. real mode is
> not
> protected mode. segments are not selectors. different word sizes make a
> HUGE difference.
Yes, which only works if you are able to write your application in
standard C, without using the extra functionality that DOS provides.
> i cant read 8gb of data in pdos-16, your not going to be able to
> keep the same api and have apps 100% compatible from pdos-16 to
> pdos-32.
No, but I can read 8k of data in pdos-16, and if the application
starts to exceed that, and suddenly requires 8 meg, a simple
upgrade to a 32-bit system is all that is required.
> I think you need to stop trying to beleive 16bit and 32bit are
> equivocal
> and interchangeable.
They should be. The only difference should be amount of memory
that they can handle.
> nobody is going to program apps/interfaces for pdos in assembler. they
> will
> use C or C++ or D or python or whatever. it does not matter what your
> api
> looks like. wrap it with a C interface and be done with it.
Which is exactly what I'm doing! And what should have been done
right from the start.
BFN. Paul.
kerravon
stu wrote:
> kerravon wrote:
> > > For OW, I haven't seen anything that indicates OW supports A.OUT. OW
> > > produces OMF. These can be linked into .EXE or ELF or many others. One can
> > > unstub OW DOS executables using DOS32A's SB.EXE unbind utility.
> >
> > And what do you get when you unstub them?
>
> linear executables "LE"
Does anyone besides OW use LE format?
BFN. Paul.
kerravon
Rod Pemberton wrote:
> Ugh, learning curve. They probably have more advanced versions of CVS
> today. But, the CVS program I dl'd a few years ago was a command line
> @#$^ing nightmare...
It is worth the effort to learn how to use CVS. I use it from the
command line.
> I know most people who've used CVS and Perforce seem to prefer Perforce. I
Anything that does a 3-way diff is fine. 3-way diff using project-wide
labels/branches.
> personally just prefer a way to get the current version of everything as
> .zip, .tgz, .bz2 or .rpm via an http link (too old school?).
Sure. That is a reasonable request too!
BFN. Paul.
stu
kerravon wrote:
>
> Does anyone besides OW use LE format?
>
os2 uses it as its native filetype and windows uses it for VXD files.
you can still
find em on XP machines.
-stu
Maxim S. Shatskih
> at least two levels deep) using the DOS functions you need to manually move
> that special structure that's used for searching by DOS...
What do you mean under "manually move"? I have the dir tree recursor object
portable across Win32 and UNIXen, with very small amount of #ifdefs.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Rod Pemberton
"Alexei A. Frounze" <ale...@chat.ru> wrote in message
news:T-ydnQhxTZGhdx3Y...@comcast.com...
> kerravon wrote:
> ...
> > The standard C library using fopen etc provides only a skerrick of the
> > functionality of DOS. If someone wants to write a sophisticated
> > application
> > instead of a command line tool, they need to use the DOS API, or even
> > directly manipulate the hardware. Are you saying that Windows and
> > OS/2 shouldn't have provided the enormous API either, that everyone
> > should be writing command line tools that purely process text files?
> > Not even allow directory traversal tools?
>
> Oddly enough, DOS' findfirst/findnext functionality is harder to use than
> POSIX opendir()/readdir()/etc.
I've not used opendir/readdir.
> To traverse the directories recursively (or
> at least two levels deep) using the DOS functions you need to manually
move
> that special structure that's used for searching by DOS...
>
What? Are you using assembly or C?
A number of years ago, I wrote a search program for Stratus Continuum's that
used stacks to store the directory tree as it recursed to increase it's
speed. But, when I decided to write the same or similar program for DOS, I
just chose to use recursion by declaring the structure within the searching
procedure. The program for DOS is fast enough I didn't need to use stacks.
This is a heavily reduced version of the main loop (eliminated all
control,variable,path setup etc., and changed the flags of the control array
to readable variables):
void scandir(char *path)
{
/*... code to setup variables */
/* using recursion, data_dos needs local scope, don't make global! */
struct find_t data_dos;
if (search_for_file)
{
chdir(path);
/*... code to setup path */
_dos_findfirst(dirbuf,0xFF,&data_dos);
do {
/*... code to handle . or .. directories */
/*... code to output matched line */
if (recurse_directories)
{
if (is_a_subdir)
{
/*... code to setup dir to scan */
scandir(dirbuf);
if (delete_directories)
rmdir(dirbuf);
}
}
} while (!_dos_findnext(&data_dos));
chdir("..");
}
}
The only real problem I've had was increasing the stack size. For
OW, -k256k is added to the compile options. For DJGPP, "int _stklen =
256000;" is added to the code.
One of the things I discovered (but no one seems to believe) is that for RM
MS-DOS v7.10, _dos_findfirst and _dos_findnext will accept paths over 64
characters if the full path is passed. My largest LFN path is 224, which is
well below the 256 maximum directory or 260 maxmimum path. However, my
largest SFN path is 124 characters. The program accurately finds this path
using _dos_findfirst/next under RM MS-DOS v7.10. Also, these:
_dos_findfirst returns files whose UNSELECTED attribs are clear (i.e., use
0xFF to match all, etc.)
_dos_findnext will return files with other attribs when out of subdirs
(i.e., must check for _A_SUBDIR)
Rod Pemberton
Alexei A. Frounze
> "Alexei A. Frounze" <ale...@chat.ru> wrote in message
> news:T-ydnQhxTZGhdx3Y...@comcast.com...
>> kerravon wrote:
>> ...
>>> The standard C library using fopen etc provides only a skerrick of
>>> the functionality of DOS. If someone wants to write a sophisticated
>>> application
>>> instead of a command line tool, they need to use the DOS API, or
>>> even directly manipulate the hardware. Are you saying that Windows
>>> and OS/2 shouldn't have provided the enormous API either, that
>>> everyone should be writing command line tools that purely process
>>> text files? Not even allow directory traversal tools?
>>
>> Oddly enough, DOS' findfirst/findnext functionality is harder to use
>> than POSIX opendir()/readdir()/etc.
>
> I've not used opendir/readdir.
Too bad :)
>> To traverse the directories recursively (or
>> at least two levels deep) using the DOS functions you need to
>> manually move that special structure that's used for searching by
>> DOS...
>>
>
> What? Are you using assembly or C?
>
> A number of years ago, I wrote a search program for Stratus
> Continuum's that used stacks to store the directory tree as it
> recursed to increase it's speed. But, when I decided to write the
> same or similar program for DOS, I just chose to use recursion by
> declaring the structure within the searching procedure. The program
> for DOS is fast enough I didn't need to use stacks. This is a heavily
> reduced version of the main loop (eliminated all
> control,variable,path setup etc., and changed the flags of the
> control array to readable variables):
>
> void scandir(char *path)
> {
> /*... code to setup variables */
> /* using recursion, data_dos needs local scope, don't make global! */
> struct find_t data_dos;
> if (search_for_file)
> {
> chdir(path);
> /*... code to setup path */
> _dos_findfirst(dirbuf,0xFF,&data_dos);
I kind of missed the fact that you don't need to preserve the DTA.
...
> The only real problem I've had was increasing the stack size. For
> OW, -k256k is added to the compile options. For DJGPP, "int _stklen =
> 256000;" is added to the code.
You could unwind the recursion and allocate memory by malloc(). Not pretty,
but at least safe from stack overflows :)
> One of the things I discovered (but no one seems to believe) is that
> for RM MS-DOS v7.10, _dos_findfirst and _dos_findnext will accept
> paths over 64 characters if the full path is passed. My largest LFN
> path is 224, which is well below the 256 maximum directory or 260
> maxmimum path. However, my largest SFN path is 124 characters. The
> program accurately finds this path using _dos_findfirst/next under RM
> MS-DOS v7.10. Also, these:
>
> _dos_findfirst returns files whose UNSELECTED attribs are clear
> (i.e., use 0xFF to match all, etc.)
> _dos_findnext will return files with other attribs when out of subdirs
> (i.e., must check for _A_SUBDIR)
Oh yeah, that's a well-known misbehavior.
Alex