OS/2 Shareware BBS: 11 Util/11-Util.zip/PMFLOPPY.ZIP/PMREAD.ME

Text File | 1990-04-24 | 7KB | 135 lines

This is a first cut at putting a PM shell over the dskcpy2 program from
Brady Flowers.  I'm trying to head this toward a generic PM floppy disk
utility, and so have added a format routine.  Unfortunately, it doesn't work.
Brady's code has been modified a bit for the PM interface, and to run the
reads and writes as background threads.  This means that you can do multiple
writes at the same, each thread reading out of the buffers created by the read
thread.  This was written under OS/2 1.2, and it blows up under 1.1 (I suspect
this is due to resource differences).  If there's a great demand for a 1.1
version, I'll try to check it out, but I don't really have a 1.1 development
environment.  Otherwise, unless some catastrophic bug turns up, I probably
won't send out another version until I get the format or one of the "future
thoughts" finished,.  Of course, all the standard disclaimers about damage to
data, etc caused by the program apply.  This is public domain software, so use
it at your own risk.  I am providing full source code (including Brady's
original source), in case you don't trust the exe or want to make your own
mods.

  Files include:

dskcpy2a.zip     ; Brady's original program
copydlgs.c       ; dialog procs source code
copydlgs.dlg     ; resource file for dialog windows
copydlgs.h       ; defines for dialog windows
dskcpy.c         ; modified dskcpy2 source code
m.cmd            ; make command file (so sue me, I'm lazy)
pmcopy           ; make file
pmcopy.c         ; front end source code
pmcopy.def       ; MSC define file
pmcopy.exe       ; right, you want a description?
pmcopy.h         ; defines for main program
pmcopy.ico       ; incredible artwork
pmcopy.rc        ; main resource file
pmread.me        ; <= YOU ARE HERE


I am currently on Internet at [e-mail], various BBSs in
the Dayton area, as well as Channel 1 and Magnum.


Known Anomolies (aka features)
  o opening the drive door during a disk operation doesn't bring up an error
    until it's closed again.  This is due to the way the driver handles the
    "disk change" line rather than an actual bug in the program.
  o since all screen updates happen in messages other than paint, when you
    resize the screen, message text gets lost.

other current features
  o single read/multiple copies of disk - no disk swapping (from DSKCPY2)
  o PM interface
  o all disk I/O occurs on background thread - no slowdown to other PM apps
  o can write multiple copies simultaneously (although at least on my
    system, making two copies in parallel is slower than two copies linear)

some possible thoughts for the future:
  o show graphically the percentage done (modify the DisplayStatus routine)
  o be able to read from two different disks at the same time (separate
    source buffers)
    - add a disk compare function



Technical Notes:

The changes to Brady's code are relatively minor.  Apparently the
BIOSPARAMETERBLOCK bug has been fixed in 1.2, because my header file matches
what he had defined locally.  Since they were the same, I removed the local
copy.  The OpenDrive funtion has been integrated into the disk functions.
This is to keep the drive handles local to the thread.  Also, errors are now
handled through a common error handler, which posts a message to the parent
window - this is because background threads aren't allowed into the
presentation space (or, if they are, it wasn't obvious to me).  Thus, I have
three classes of messages being passed forward - Error, Status, and General.
Currently the "General" messages are only passing Done up, but I wanted to
leave it open for future use.

Ah, the format.  This has caused me quite a bit of pain.  I really thought I
had this one beaten, but I'm out of "play time", and it still doesn't work.
If you enable the menu option (in the WM_INITMENU case for the main window),
you can see what it does currently.  It will go through the disk, formatting
each track (and dieing on errors - perfect disks only).  It will then build
the root track based on an algorithm from Writing OS/2 Device Drivers (by
Raymond Westwater, Addison-Wesley, p. 496), but when I go to write out the
track, the IOCtl returns an invalid parameter.  Other unsolved format issues
involve detecting a low density disk (unformatted) in a high density drive.
I leave the resolution to this problem as an exercise to the reader.

Having only recently come to the OS/2 world (from a wide variety of other OSs),
and being relatively unwashed in the intricacies of MSC and PM, I ran into
a few oddities only to be resolved by Spy and Logitech's Multiscope.  These I
thought I would share, hopefully to prevent others from following the same
road.  First, the disappearing window.  When I got to the point that my
main window was coming up fine, and I was spinning off threads that didn't do
anything beyond opening the drive, I added the first real task - the IOCtl to
get the BPB, and then calculate the disk parameters.  This is just straight
out of what Brady had done, so I felt relatively secure.  Well, for some
reason, shortly after the IOCtl, the window would close and the program would
shut down.  No messages, no warnings, no phone calls, just gone.  I set Spy
to work, and found that my window was receiving a WM_DESTROY message.  Well,
I certainly wasn't sending it, so it had to be PM.  According to multiscope,
I was just doing some assignment statements in my background thread when it
died.  Not til I looked closely at the assignments did I realize there was a
divide by zero.

Conclusion 1: Certain run-time errors will cause a PM app to shut down without
              warning.

Now, why was there a divide by zero?  This was just straight out of Brady's
original program.  I went back and recompiled his code under my make, and
found that his did the same thing.  Again, multiscope to the rescue,  the
IOCtl was returning fine, the data was there and fine, but the structure wasn't
interpreting it correctly.  Linker alignment?  No, actually compiler alignment.
As I said, I'm new to MSC, and they have a -Zp parameter for packing.  Not
that it's documented anywhere on the IOCtl call, but Brady's program used it,
and when I created my make, I left it off.  Problem solved.

Conclusion 2:  Beware of compiler alignment as well as Linker alignment.

The invisible dialog:  This one was actually simple, but again, it might save
someone a few minutes.  A couple times I had dialog boxes that looked fine,
all the code was in place, but they just wouldn't appear.  It turned out that
one of my resource IDs was incorrect in the .DLG file.  Nobody would complain,
but they also wouldn't comply.

PM programming is actually quite interesting.  The quality of the tools is
very good.  I've been playing recently with other programs, like Smalltalk/V
PM and Object/1.  I've done some great prototypes very quickly with ST/V, but
both products seem to need to mature a bit in the PM world.  Thanks again to
Brady Flowers for the disk handling routines. Now I'd better get back to
something that'll make the company money - unfortunately, I can't spend all
my time just learning about the new stuff.

24 April 90
gb