SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, 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.

The Southern California OS/2 User Group
USA

SCOUG-HELP Mailing List Archives

Return to [ 30 | August | 2001 ]

>> Next Message >>


Date: Thu, 30 Aug 2001 11:49:22 PDT
From: "mrakijas" <mrakijas@oco.net >
Reply-To: scoug-help@scoug.com
To: <scoug-help@scoug.com >
Subject: SCOUG-Help: Video driver install problem

Content Type: text/plain

=====================================================
If you are responding to someone asking for help who
may not be a member of this list, be sure to use the
REPLY TO ALL feature of your email program.
=====================================================

** Reply to note from "Steven Levine"

Tue, 28 Aug 2001 18:28:27

-0700

> Here's a couple of new tools.
>
> showqsv just lists the systems values that happen

to contain the drive
> letter. Use it to confirm that OS/2 really thinks

you are booting from
> drive D:. :-)

Here's the output, and as expected, something thinks

I am booting from drive D:

260 Maximum length, in bytes, of a path

name.
16 Maximum number of text sessions.
16 Maximum number of PM sessions.
1025 Maximum number of DOS sessions.
4 Drive from which the system was

started (3 = C:). [!!! -Rocky]
1 Dynamic priority variation flag (0 =

absolute , 1 = dynamic).
1 Maximum wait in seconds.
32 Minimum time slice in milliseconds.
64 Maximum time slice in milliseconds.
4096 Memory page size in bytes (4096 for

the 80386).
20 Major version number.
45 Minor version number.
0 Revision number.
300515 Value of a 32-bit, free-running

millisecond counter.
999171117 Low-order 32 bits of the time in

seconds since 1/1/1970.
0 High-order 32 bits of the time in

seconds since 1/1/1970.
133758976 Total number of bytes of physical

memory in the system.
14716928 Total number of bytes of resident

memory in the system.
978395136 Maximum bytes that can be allocated

by all processes.
318111744 Maximum bytes process can allocate

in private arena.
272498688 Maximum bytes process can allocate

in shared arena.
310 Timer interval in tenths of a

millisecond.
255 Maximum length, in bytes, of one

component in a path name.
19 Session ID of the current foreground

full-screen session.
55 Process ID of the current foreground

process.
1 Number of processors.
469762048 Maximum free space in process's high

private arena.
469762048 Maximum free space in process's high

shared arena.
1025 Maximum number of concurrent

processes supported.
1024 Size of the user's address space in

megabytes.
1 QSV_31.
0 QSV_32.

> pmdll v2.9beta3 is for you to be my guina pig. I

used your font troubles
> as a catalyst for updating the font validation

logic. The original code
> was way to conservative.

The new version at least lets the program get

started despite the two errors but the two errors,

of course, persist: Could not open font file and

could not find D:\CONFIG.SYS

> Also, an fdisk /query for the system we are

working on would be helpful.

Sorry if the columns get messed up but I'm using my

ISPs Web e-mail client which doesn't permit good

control.

Drive Name Part Vtype FStype Status Start Size

1 0000003f C: 1 07 2 0 1275

DFSee and PartitionMagic both produce no errors when
checking the drive.

Funky, huh? You'd think that if it thought that

drive D: was the boot drive, it eventually couldn't

continue. That could be why the addition of the

DaniDASD.DMD driver with it's assignable boot drive

command line argument fixed (or at least helped) to

allow booting to continue. It must be happening

before the config.sys is processed. Ahhhh. How's

this sound? I don't recall the sequence I used but

I might have done the SYSINSTX command on the drive

after the XCOPY but before the drive was the lone C:

drive on the system. Should I redo the SYSINSTX C:

after I boot to floppy? Could this be it?

> Steven

Thanks again for the help.

-Rocky

____________________________________________________
__
Sent via the oco.net WebMail Server

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-help".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


>> Next Message >>

Return to [ 30 | August | 2001 ]



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.