OS/2 vs DOS vs Windows for memory access

OS/2 vs DOS vs Windows for memory access

Post by Kevin Mey » Thu, 25 May 1995 04:00:00



This is from my original posting to the Windows, OS/2 and DOS groups.. but
someone suggested "Try Linux", so I'm asking you people too...

"For it is said, go not to the Usenet for advice; for it will say both yes
and no, and quite a few things you can't relate to the actual question" -
Martin Walker

Ok knowing the above, I'm here anyway, and this time money will be spent on
the results. Please people, I need information, not mere opinions.

We are about to embark on several large projects which require real-time
image processing. We don't have an extremely large budget so Sun systems are
out, but PCs are in, as long as the image grabber isn't too expensive [like
US$3000] and the primary developing platform will be C.

PROBLEM:
I need to be able to directly manipulate memory at a specific high memory
location, for example at 11 meg. This memory is the card memory of a image
grabber. Presently, to the best of my knowledge, this is physically
impossible under DOS.

The images will all be about 256k to 380k in size, and need to be globally
addressable all the time: IE I need to be able to access pixel at (0,0) and
at (767,255) without having to swap memory about.

My options are:
DOS: Use DPMI or some such extended memory manager to bring the memory to
conventional space, manipulate it, and use same manager to put the memory
back.. Are there any 32 bit protected mode DOS compilers?
CONS: Slow. Very slow.

Windows: I have no idea. Was told to use Selectors, but could never get them
to correctly access the memory in question.
CONS: Slow. 16 bit. [Yeah, yeah, scream all you like about win32s.. How do I
access high memory directly [if I know the linear address] in win32s?

OS/2: Again, I have no idea. How do I go about accessing a known linear
address in OS/2?

LINUX: No info. Code fragments on how I'd go about it?
CONS: Machine cannot run any Windows apps? [Is this a problem, probably not]

I'm in favour of using OS/2 because I believe if it can allow me to access this
physical memory directly, ie by making a char pointer point to it, then I'll
be able to take advantage of an up and running 32 bit OS to access the whole
image and several buffers. But I have no solid info on how to go about doing
this in OS/2.

I'll be writing my own drivers, if need be, though cards under consideration
are the Creative Labs SE200 [SE100?] video blaster, and similar. The DT 3851
card, while nice, VERY NICE, is also very pricey.

So if you all out there could show me how I'd go about accessing 400k images
on the card's own memory in C under your favourite platform [DOS protected
mode, Windows, Win32s, OS/2 PM, OS/2 native], I'll then look at the platform
and method and make a decision [taking into account whatever other information
you give..]

Other hardware platforms are also acceptable options, but we'll be writing
our own applications.

Simple, isn't it?

--

This is not mine, I had nothing to do with it.| #include <std_disclaimer.h>
Kevin Meyer, Plasma Physics Research Institute|Everyone knows the war is over
University of Natal, Durban, South Africa     | and the good guys lost - LC.
         http://flyer.ph.und.ac.za/users/kev/welcome.html

 
 
 

OS/2 vs DOS vs Windows for memory access

Post by R.Zimmerma » Tue, 30 May 1995 04:00:00


: PROBLEM:
: I need to be able to directly manipulate memory at a specific high memory
: location, for example at 11 meg. This memory is the card memory of a image
: grabber. Presently, to the best of my knowledge, this is physically
: impossible under DOS.
Under plain DOS, yes. It might (*might*) be possible under some 32 Bit
DOS extender platform, though.

Anyway, you'll very probably want to use a 32 Bit platform, and this
will be easiest under a real 32 Bit OS, that is, OS/2 or Linux.

: The images will all be about 256k to 380k in size, and need to be globally
: addressable all the time: IE I need to be able to access pixel at (0,0) and
: at (767,255) without having to swap memory about.

: My options are:
: DOS: Use DPMI or some such extended memory manager to bring the memory to
: conventional space, manipulate it, and use same manager to put the memory
: back.. Are there any 32 bit protected mode DOS compilers?
: CONS: Slow. Very slow.
If you manage to actually MAP the memory into your app's address space
(not merely copy it) it might not be that slow.
Anyway, running 32 Bit apps under last century's operating system
software :) is rather more likely to cause awkward problems.

: Windows: I have no idea. Was told to use Selectors, but could never get them
: to correctly access the memory in question.
: CONS: Slow. 16 bit. [Yeah, yeah, scream all you like about win32s.. How do I
: access high memory directly [if I know the linear address] in win32s?
No idea.

: OS/2: Again, I have no idea. How do I go about accessing a known linear
: address in OS/2?
NO idea either. It might be easier than Windoze, though. :)

: LINUX: No info. Code fragments on how I'd go about it?
Well, I haven't got the details at the moment, but it's rather easy:

very roughly, how to map a physical memory address into the user
space (i.e. I assume you want to access it from a program, not from
a kernel driver.)
(this is just to show the principle, don't quote me on the details.)

void map_framegrabber() {
  int fd;
  fd = open("/dev/kmem",O_RDWR);
  /* map 400k physical block at 11Meg into process space /*
  framegrabber_ptr = mmap(NULL,400*1024,PROT_READ|PROT_WRITE,
                          MAP_SHARED,fd,11*1024*1024);
  close(fd);

Quote:}

I'm not sure if it's /dev/kmem, /dev/mem, /dev/kcore or something...
If it's implemented yet (?), you might use phys() instead, which
should be a little bit easier.

when finished with it:
munmap(framegrabber_ptr,400*1024);

You'll probably have to run this as root.

hope this helps...

: CONS: Machine cannot run any Windows apps? [Is this a problem, probably not]
It can, more or less. WINE (the Linux Windows emulator) is under way,
and allegedly it is possible to run windoze3.1 under dosemu (though
maybe not without problems).

: I'm in favour of using OS/2 because I believe if it can allow me to access this
: physical memory directly, ie by making a char pointer point to it, then I'll
: be able to take advantage of an up and running 32 bit OS to access the whole
: image and several buffers. But I have no solid info on how to go about doing
: this in OS/2.
You'll get the same advantages under Linux :-)

-Rainer

 
 
 

1. DOS vs. Windows vs. Mac vs. Unix vs. NS

The C standard dictates that SEEK_SET, SEEK_CUR and SEEK_END (among others)  
must be #defined in stdio.h.  This is not a POSIX requirement.  The only  
POSIX constraints on stdio.h are that it must #define L_ctermid and  
STREAM_MAX and declare fdopen() and fileno() if _POSIX_SOURCE is #defined.  
It may optionally #define L_cuserid if _POSIX_SOURCE is #defined.

POSIX 1003.1 _does_ however, require that unistd.h #define SEEK_SET &c if  
_POSIX_SOURCE is #defined.  Thus, if you desire POSIX conformance, #include  
unistd.h.

Are you sure about the SunOS headers?  Here's a test I ran on my SPARC at  
work:

% fgrep SEEK_SET /usr/include/unistd.h
#ifndef SEEK_SET
#define SEEK_SET        0       /* Set file pointer to "offset" */
% uname -a
SunOS epimbe 4.1.1 1 sun4c

Perhaps they've moved unistd.h to /usr/5include since 4.1.1??

I do agree on this, and am rapidly tiring of system dependencies being  
handled by #ifdefs.

I've found the "POSIX Programmer's Guide" (Donald Lewine, O'Reilly, ISBN  
0-937175-73-0) to be priceless.  I strongly recommend this book to anyone  
using C, whether they be UNIX programmers or not (but particularly if they  
are).  It not only helps understand "what is defined where and by which  
standard", but also helps programmers to "Do the Right Thing" by clarifying  
what is POSIX conformant and what is historical baggage.

--
-----------------------------------------------------------------------------
Jim Vlcek                         UNIX for $166!
uunet!molly!vlcek                 Novell UnixWare from Information Foundation

2. setproctitle and solaris

3. Linux/XFree speed vs OS/2 vs DOS/Windows

4. Forbidden

5. OS/2 vs DOS/Windows vs Linux re: Interrupts

6. Storing A Postscript File In A HP Printer's Memory

7. Desktop vs Window Manager vs X11 vs OS

8. Solaris 1.1.1 Patch Integration List: 07/Jan/94

9. Linux Advocacy - Linux vs Windows 2000 vs Be vs OS/2

10. Linux vs OS2 vs NT vs Win95 vs Multics vs PDP11 vs BSD geeks

11. Linux vs Windows vs DOS future.

12. *nix vs windows/dos vs macOS structure

13. Linux vs Windows vs DOS future.