said:
>
> >If you do not need to read these packed 1.8meg diskettes, then you do not
> >need the SCFLOPPY.FLT basedev device statement. Having it only takes up a
> >little virtual memory that gets swapped out.
>
> That's what I thought. Dallas, though, raises the possibility of that
> creating a conflict - do you have any sense of the liklihood of that? --
> - Mark
> -----------------------------------------------------------
> marka@relaypoint.net
> Note new E-mail address
> -----------------------------------------------------------
>
(Excuse my rambling degression off the deep end
here, but maybe these vaguely formed ideas
could help, I can't resist more speculation... )
(Previous item: Yes, IBM1FLOPPY.ADD is in CONFIG.SYS, it
shows up on bootup, but can you confirm that it has not been
modified by installation on the virtual PC? Is it the same length,
does it have the same checksum etc.? Leave no stone unturned!)
Another thought on this - try making an XDF disk image
with XDFCOPY as an experiment,
to see if it works. Also try making disk images with the other
tools to make disk images. (some differ slightly as I recall).
Also, there are some "For use by IBM use only" disk image tools on
the installation CD-ROMs that might be worth experimenting with also.
Maybe they bypass the virtualization, and can provide some more clues.
Does Win95 virtualize the floppy? My guess is not, based on Mark's
experience.
A DISKCOPY tool comes with DR-DOS 7 that creates an image that differs
from all of the above.
I cannot run it directly from a DOS session in OS/2.
It can be run from a Specific DOS session if first you do
FSACCESS A=A (Ayn Rand's favorite computer command :-) ),
then FSACCESS ! A:, which apparently causes
it to bypass all the virtualization, and enables this version of DISKCOPY
to work using lower levels calls.
These steps also still allow access to A: (on my computer), but a lot slower
then previously.
So anyway, what all this is leading up to is, if you could get a
bootable image of a DOS disk over to the PPC, would this
FSACCESS A=A then FSACCESS ! A: allow access, via
the booted DOS, to A:?
Alternate method to try this: Install OS/2 so as to share the
Hard Drive image with PC-DOS 7, and do a Specific DOS boot off
of C:. This can be done if the two OS's share the Hard Drive image
with Boot Manager, or if they share it with Dual Boot, and you
use the poorly documented BOOT switch to set up booting DOS without
a shutdown. ("Boot /DOS /N")
(I think there are some other ways, but they are even more obscure,
but enough for now already!)
Thanks for setting up this mailing list!
Regards,
Dallas E. Legan II
(562) 862 - 4854 ext. '*'
D <- Parse this, SpamBots! :-)
A ******************************************************
L "But I found that the Rulers were
L L A L ordinary men, too, and frequently
E E W A as bewildered as I was."
G G 5 S "Solution Unsatisfactory",
A A 8 I Robert A. Heinlein
N N 5 I ******************************************************
@ OR @ OR @ OR @ I speak only for myself, and assume
A F L K full responsibility for my statements.
C I A I
M G F N
. . N C
O O . Y
R R O B
G G R .
G C
O
M
=====================================================
To unsubscribe to this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-general".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
>> Next Message >>
Return to [ 24 |
February |
1998 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
