The World of Computer Software/World_Of_Computer_Software-02-387-Vol-3of3.iso/v/v93n02y.zip/V93N024.IBM

Internet Message Format | 1993-02-17 | 29KB

From:    WF02::IN%"[e-mail]" 16-FEB-1993 23:44:47.25
To:    James Gerber <[e-mail]>
CC:
Subj:    Info-IBMPC Digest V93 #24

Return-path: $$INFOPC
 <@WS5.CIS.TEMPLE.EDU:$$[e-mail]>
Received: from JNET-DAEMON by GRAD.CIS.TEMPLE.EDU; Tue, 16 Feb 93 22:43 EST
Received: From TEMPLEVM(MAILER) by TMPLCIS with Jnet id 5194 for
 GERBER@TMPLCIS; Tue, 16 Feb 93 22:43 EDT
Received: from TEMPLEVM.BITNET (NJE origin LISTSERV@TEMPLEVM) by VM.TEMPLE.EDU
 (LMail V1.1c/1.7e) with BSMTP id 8717; Tue, 16 Feb 1993 21:43:41 -0500
Date: Mon, 15 Feb 1993 16:40:50 GMT+1
From: Info-IBMPC Digest <[e-mail]>
Subject: Info-IBMPC Digest V93 #24
Sender: Info-IBMPC redistribution list <$$[e-mail]>
To: James Gerber <[e-mail]>
Reply-to: [e-mail]

Info-IBMPC Digest           Mon, 15 Feb 93       Volume 93 : Issue  24

Today's Editor:
         Gregory Hicks - Rota Spain <[e-mail]>

Today's Topics:
                      .com and .exe files (3 msgs)
           Can you run an XT on it side? (among other things)
                     Disappearing diskette drives?
                   Diskette read errors and data loss
                            dual IDE drives.
                 Expanding the size of a disk partition
                        EXTENDED memory accesses
                    Help - DOS commands from program
   Deleting disk partition with DOS 5.0 (don't know volume) (2 msgs)
                 multiple mouse cursors on my screen!!
                   PC/AT System Board Initialization
                   Protected mode source code example
                 Stacker Drive write-protected somehow
                 SUMMARY: UNIX-style links under MS-DOS
                Undocumented config.sys params (2 msgs)

Send Replies or notes for publication to: <[e-mail]>

Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to: <[e-mail]>

Addition and Deletion requests for UK readers should be sent to:
<[e-mail]>

Archives of past issues of the Info-IBMPC Digest are available by FTP
ONLY from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.

----------------------------------------------------------------------

Date: 28 Jan 93 10:15:25 GMT
From: "M.E. Edwards" <[e-mail]>
Subject: .com and .exe files

[e-mail] (Frank E. Prince) writes:

>Could anyone tell me the difference between .com and .exe files. The
>most I've come up with is that a com file is an "executable memory image"
>but that definition was somewhat out of context, and I don't really
>understand it. I've done some assembly language programming with MASM so
>I do understand instruction sets, stacks, registers etc. Any information
>regarding this is much appreciated.

I've posted this since it may be of general interest to others as well.

As far as I understand, a .com file is a direct memory dump (ie no code
relocation can take place) whereas an .exe file contains offsets and
indirection allowing it to be run from (more or less) any location in
memory.

Thus, a .com file can be loaded and executed slightly faster than
an.exe file since the processor only has to load the code to a set area
(usually the base of user memory) and jump straight to it.

The only problem with .com files is that there is no separation between
the code segments.  Thus the stack and data segments share the same
memory area.  Thus some compilers may throw out the code.

Using Borland Turbo C++, I find that the tiny memory model will
suffice, so compile your code with that and as long as the executable
file is less than 64k in length then quit to dos and type :

                        exe2bin <filename>.exe <filename>.com

and this will transform your .exe file into a .com file (so now we all
know what this little DOS utility is for :-) ).

So, hope this helps?

Cheers,  Mark...

   Snail Mail : M.E.Edwards,204 Farndale Road, Benwell, Newcastle-Upon-Tyne.
   Email : [e-mail]                  Phone : [phone]
           "Do not adjust your mind ... there is a fault in reality"
#include <StdDisclaimer.h>

------------------------------

Date: 26 Jan 93 16:10:19 GMT
From: "Pardhasaradhi A. Reddy" <[e-mail]>
Subject: .com and .exe files

The following are some notable differences between .com and
.exe files :

.com : All the three segments namely CODE, DATA and STACK point to the
same segment. In other words, the program can only occupy 64k memory.

A .com file has no header like that of a .exe file. Such a program is a
exact copy of how the same program would look if loaded into memory.

.exe : Can have any no. of segments for CODE, DATA and STACK.

It has a header that stores the info about the address of the first
executable instruction, relocation info. etc.

The following book gives a detailed description of the differences :

        IBM Assembler language  -> Peter Abel.
Also , Advanced MSDOS  -> Ray Duncan (the best)

        regards,
        Pardha.

--
 Disclaimer : Views expressed by me are purely mine and have nothing to
do with those of my employer's or any Organization. Reader's discretion
is strongly advised.

------------------------------

Date: 28 Jan 93 21:31:45 GMT
From: Paul Erickson <[e-mail]>
Subject: .com and .exe files

... [After discussing differences between .com and .exe files,
[e-mail] (Michael R Castle) asks:

>Question:  Can't com files use more than 64k?  Once the program is going,
>you can pretty much do what ever you want with the segment registers, and
>request more memory, and access the full 640 k.

the standard action of a com file is to locate the data, stack and code
all within one segment.  However, their is not this limitation on the
heap.  Therefore, the program can allocate as much memory (malloc or
getmem or new) as the machine has availiable.  Also the CS and DS
segment registers can be modified directly, but unless you are
experienced with how DOS handles memory this is not a good idea.

------------------------------

Date: Thu, 4 Feb 93 12:55:42 EST
From: [e-mail] (William Grant)
Subject: Can you run an XT on it side? (among other things)

I ran an old PX XT clone on its side for many years.  It works just
fine, but there are a few points to keep in mind:

        a) backup the HD, completely reformat it while on its side,
restore your backup (The older drives would get slightly out of
alignment when on their side.  Formatting them this way solves it.)

        b) keep the machine at least a little off the floor (This helps
avoid dust and flooding problems)

        c) vacuum it out occasionally (Check internally from time to
time and determine how long you can go without in your situation.)

Best of Luck

Disclaimer:
   Whatever you say, say nothing, when you talk about you-know-what,
   For if you-know-who should hear you, you know what you'll get.

Leprechaun Liam                                 [e-mail]
Code 5541, NRL, Wash. DC 20375-5337,  [phone] W  [phone] H

------------------------------

Date: 29 Jan 93 14:08:17 GMT
From: Lance Hartmann <[e-mail]>
Subject: Disappearing diskette drives?
Keywords: diskette windows win3.1 msd checkit
Summary: Floppy drives vanish over time from system configuration.

Does anyone know EXACTLY how CHECKIT and Windows' MSD diagnostic
programs check the existence and type of diskette drives on a system?

I've been plagued with a problem over the past couple of months whereby
my diskette drives, A: and B:, mysteriously vanish from all dialog
boxes under Windows 3.1 after I've been working awhile (a couple
hours).  Despite the fact that the drives do NOT appear in DISK popups
and File Manager, I am still able to access the drives; likewise for
DOS.

Recently, when I noticed that the drives "disappeared" from Windows, I
exited and re-started Windows.  No dice -- drives still missing.  I
exited Windows again (NOT escaped, but terminated it) and then ran the
CHECKIT program.  Upon selecting the CONFIGuration option, CHECKIT
reports that the diskette drives are missing too!!  The hard drives C:
and D: are still there, but the floppies are gone.  Again, I'm still
able to access the floppies, but even CHECKIT under a "pure" DOS
environment states they're missing!

I decided then to run Windows' MSD program.  Upon doing so, it
SUCCESSFULLY finds the diskette drives and even reports their
configuration (5.25, 3.5, etc.).  I find it particularly confusing that
Windows' diagnostic program locates the diskette drives, but the
Windows' environment cannot!  I can toggle back and forth between
running CHECKIT and MSD.  Each time, CHECKIT shows no floppies, and MSD
does find them!  Upon a hard reboot, the floppies re-appear everywhere
(Windows, Checkit, etc.).

I'll probably take my machine into the shop, but if anyone has any
insight to what may be going on, I'd really like hearing from you.

My system:  486DX50 (NOT DX2 -- yes, I have a heatsink/fan, too),
            256K cache, 8MB RAM, AMI BIOS, ETEQ chipset, ISA bus at
            regular speed, Promise Technology DC-2040 SCSI controller.

Thanks to all in advance,
Lance Hartmann ([e-mail])
               Yes, that IS a '%' (percent sign) in my network address.

All statements, comments, opinions, etc. herein reflect those of the author
and shall NOT be misconstrued as those of IBM or anyone else for that matter.

------------------------------

Date: 1 Feb 93 14:13:38 GMT
From: Johannes Beekhuizen <[e-mail]>
Subject: Diskette read errors and data loss.

Hello Frank,

On Friday January 29 1993, Frank Slootweg CRC wrote to All:

 >> controller.   If the drive and/or controller is bad, then that does
 >> not really  explain why my son is not having any problems on my
 >> system, but  perhaps/probably he also sometimes writes his diskettes
 >> on another  computer (mainly at his friend) and this

I had this problem once, on diskettes which I wrote to, tested, and
then put in the box. Some weeks later they had errors. It turned out
that they were standing to close to the monitor, which emitted a very
strong megnetic field when switched on or off.

Regards,

           Hans.

fidonet  2:281/527.5
yan-net  123:3183/101
e-mail   [e-mail]

------------------------------

Date: 1 Feb 93 08:01:02 GMT
From: Clifton R Peterson <[e-mail]>
Subject: dual IDE drives.

As I understand IDE drives, if you have two of them, you need to
designate one as the "MASTER" and the other as the "SLAVE".  This is
generally accomplished by means of jumpers on the drives themselves.
What this does is make the SLAVE wait 4 seconds for spinup after power
application to both reduce the demain on you power supply and ensure
that the master is the boot drive.  I don't have any documentation for
your older drive, but for the Western Digital, the following should
apply.

The jumpers you need to look for is the J8 which should be at the back
of the drive just to the left of the power connector.

For single Western Digital;

        5  3  1
       ---------
      | o  o  o |
      |         |
      | o  o  o |
       ---------
        6  4  2

Master drive configuration (jump pins 5 and 6);

        5  3  1
       ---------
      | +  o  o |
      | |       |
      | +  o  o |
       ---------
        6  4  2

Slave drive configuration (jump pins 3 and 4);

        5  3  1
       ---------
      | o  +  o |
      |    |    |
      | o  +  o |
       ---------
        6  4  2

I hope this helps and is actually accurate.
--
 _________________________________________________________________________
/ Clifton R. Peterson    1108 Burnett           [phone]             \
| B.S. Chem E            Ames IA  50010                                   |
\_______________"42"_is_one_hell_of_an_answer!!___________________________/

------------------------------

Date: 28 Jan 93 21:55:04 GMT
From: Paul S Secinaro <[e-mail]>
Subject: Expanding the size of a disk partition

Assuming I have removed all the other partitions on the hard disk, is
there any way to safely increase the size of the primary C: partition
without losing any data?  Are there any reliable utilities that will do
this?

In case it matters, I'm using a Maxtor Panther P0-12S 1.2GB SCSI hard
disk and a DTC 3290HD SCSI EISA controller.  I have a primary partition
of 200MB and an 800MB extended partition (DOS 5.0 format).  I'd like to
expand the primary to at least 400MB.

Thanks!

Paul

--
Paul Secinaro
[e-mail]
Synthetic Vision and Pattern Analysis Laboratory
UNH Dept. of Electrical and Computer Engineering

------------------------------

Date: 27 Jan 93 16:19:02 GMT
From: Roman Baker <[e-mail]>
Subject: EXTENDED memory accesses
Keywords: extended emm386

I need to develop a program that will access memory in the 1M-16M
memory range.  I realize that I will probably have to go through a
memory manager (like emm386, QEMM, 386Max) but could someone tell me
the procedure for accessing this memory.  Also, what addresses are
going to show up on the bus if I access C00000?

Thank you,

Roman Baker
National Semiconductor Corp

------------------------------

Date: 27 Jan 93 02:31:43 GMT
From: "G. David Douglas Jr." <[e-mail]>
Subject: Help - DOS commands from program...

[e-mail] (Jeff Meyers) writes:

>I have written a simple installation program in Turbo Pascal and am having
>trouble executing DOS commands from within this program.

>If the user types "a:install" everything works fine.  But, if they log to
>the floppy first, then run install ( A:\>install <cr> ) things choke.

>Specifically, the destination directory is not created and so the files
>are all copied into a file in the root directory.  I use the Turbo Pascal
>command exec() to call the following command:

>    \command.com /C md C:\DEST

>I also had trouble logging drives and changing directories under program
>control, but got around that by haveing the install program create the
>appropriate batch file, then executing it...

>Question: am I missing something? Why don't the DOS commands work the
>same as at the command line??

Well, ideally I'd like to have more information, but here's a hunch:

Does the floppy disk you're trying to run the utility from have a copy
of COMMAND.COM on it?  If not, and if you're trying to execute
\COMMAND.COM instead of C:\COMMAND.COM, for instance, it probably won't
work -- can't find COMMAND on the floppy disk, so can't execute it.

Also, I don't know which version of Turbo Pascal you're using, but:
does a command like getenv (or get environment entry) exist in your
version?  If so, you could retrieve the (it _should_ be there) string
associated with the COMSPEC environment variable, and use THAT for the
drive-name/directory-path to a copy of COMMAND.COM to execute.

Just my opinion on what MIGHT be wrong.

One last note:  I once wrote a utility (under Turbo Pascal 3.1 (old, I
know :-)) that does some of the operations (change drive, change
directory, etc.) you describe; problem is, nothing like the  exec
command was around (had to write my own code to do that).  If I
remember correctly, version 3.1 had a command called  chdir  (change
directory) -- does yours?  (Change drive was something else -- I ended
up using the DOS-services (MSDOS ?) function to change disk drive,
change file attributes, etc.) Drop me a line if you'd like a copy of
the source code (now just collecting dust on my disk drive :-).

David Douglas
[e-mail]

------------------------------

Date: 30 Jan 93 03:38:57 GMT
From: Todd Booth <[e-mail]>
Subject: How to delete disk partition with DOS 5.0 (don't know volume)

My hard disk is hosed.  How do I delete the primary disk partition when
I don't know the volume name.  DOS requests the volume name but I don't
know how to enter it since it is all in special characters (>128) and I
don't know the ascii map.  I am aware of the ALT+decimal method but
don't know the required chars.

--todd

------------------------------

Date: 1 Feb 93 01:54:19 GMT
From: Doug Merrett <[e-mail]>
Subject: Deleting disk partition with DOS 5.0 (don't know volume)

Use Norton Utilities (et al) to fill the first physical sector with 0's

Doug Merrett
Internet: [e-mail]

------------------------------

Date: 1 Feb 93 01:27:23 GMT
From: Leonard Erickson <[e-mail]>
Subject: multiple mouse cursors on my screen!!

[e-mail] writes:

>I'm writing a text-editing program in BC++ to take advantage of the
>extended text modes of my video card.  The windowing structures work
>fine in the normal text modes (80x25, 80x43/50), but when I switch to
>the 132 column x 44 row mode, I get sixteen (16) mouse cursors!
>I move the mouse, and sixteen text cursors float all over the screen,
>leaving "garbage" characters behind them.

>I want to make my application self configuring, so that it would adapt
>itself to the text resolution of the system when the program was
>called.  (So that I (or any one else) could set the resolution to the
>desired width and height at the dos command line and call my program.)

>Do I need a special video driver to run in extended text mode?  (I
>noticed that the conio.h functions would not show up in the extended
>text mode in some other programs.)  My video card is built into my
>motherboard.  It has a Western Digital chip and 512k video memory.

The problem is the *mouse* driver. Microsoft *hard-coded* the modes
into the driver. Whatever mode number your card uses for 132x44 *text*
mode is one that Microsoft has assigned as being a *graphics* mode. So
the driver is trying to do a *graphics* cursor (with the results you've
seen).

It took me two weeks of digging to get Microsoft to admit that. And
they have the gall to claim that the *cards* are broken, not their
driver.  They claim that the modes are non-standard (so what are the
modes they support?)

Here are the relevant sections of my email with Microsoft:

Subj:  Mouse text cursor                       Section: Mouse/Paintbrush
From:  Leonard Erickson                        # 135785, 1 Reply
  To:  Bill Starbuck            70042,344      Date: 02-Mar-92 17:38:00

Bill,
        For what it's worth, the compaq (like most cards with extended
text modes) assigns mode numbers to the "non standard" modes. Here's a
table of a few of the modes ("mode" is the *decimal* value stored at
$0040:$0049,col is $0040:$004A, and rows is $0040:$0084 + 1)

mode    cols    rows
3       80      25      color
34      132     43      color
35      132     25      color
36      132     28      color
39      132     50      color
40      132     60      color

In none of these modes does the cursor info (word at $0040:$0060) have
the "graphics" bit set.

I seem to vaguely recall hearing that the Microsoft mouse drivers
*assume* that modes above some number are graphics modes. I hope not,
as that is a *bad* assumption! But I am curious as to how they *do*
make such a determination...

 Subj:  Mouse text cursor                       Section: Mouse/Paintbrush
From:  Hardware(SL)             76701,244      # 135845, 1 Reply
  To:  Leonard Erickson                        Date: 02-Mar-92 21:10:01

Leonard,
     You have just sort of hit on your problem.  The hex video mode you
are running is not on that is supported by the 8.x Mouse Drivers.

     The only hex modes that are close are:

41 - 132 x 25
42 - 132 x 43
44 - 100 x 60
45 - 132 x 28
60 - 132 x 25
61 - 132 x 50

    So, if you can switch into any of these hex video modes, you
shouldn't have any more problems.

Ron White - Microsoft Product Support

Leonard Erickson                      [e-mail]
CIS: [70465,203]                         [e-mail]
FIDO:   1:105/51         [e-mail]
(The CIS & Fido addresses are preferred)

------------------------------

Date: 28 Jan 93 22:24:48 GMT
From: Steve Morvai <[e-mail]>
Subject: PC/AT System Board Initialization
Keywords: PC/AT Hardware Initialization
Summary: Information on initializing the PC/AT system board components

  Could someone provide information (articles, documents, referrences)
or sample sources (C, ASM) outlining the procedure to initialize the
PC/AT system board components following power-up in a similar manner
that the BIOS does.  The system components include the timer, interrupt
controller, DMA, keyboard controller, etc ... The intended purpose is
to replace the BIOS with an embedded application operating as a
diskless system.

  Replies to "[e-mail]" or the newsgroup is much appreciated.

  -SRM

------------------------------

Date: 26 Jan 93 21:48:52 GMT
From: Dennis Marer <[e-mail]>
Subject: Protected mode source code example - I'll send it to you.

In article <[e-mail]> [e-mail] writes:
>    Does anyone have any source code already typed in that they would be
>willing to share with the rest of us?  I want to try programming in protected
>mode, but I HATE typing assembly listings out of books.  Anything from books or
>your own code if you're willing to share it would be appreciated.

For anybody that's interested, I do have such an example.  At this
point, I don't guarantee it's 100% correct, but it initializes
Protected Mode from DOS, setting up the IDT, GDT, LDT, shifting
hardware interrupts so they don't conflict with the reserved Intel
interrupts, and so on.  It's very primitive at this time, but it gets
the point across.  Once in Protected Mode, it writes messages to the
screen and tests the new interrupts.  It does NOT emulate the DOS
interrupts, so this causes a few problems:

        1) The floppy drive motor stays on indefinitely
        2) You can't exit back to DOS once running this program

If you're interested, drop me some e-mail and I'll send it to you in a
couple of days.  It's completely free and copyable.  It's also got
nothing to do with my work at Intel - I don't get to play with
Protected Mode here! :-( It's very documented (over documented?) so it
should be easy to understand, given familiarity with the 386.

One more thing - it was written using Turbo Assembler, so it will
require a few modifications to assemble under MASM, etc.

                                Dennis Marer
                                [e-mail]

-- Not speaking for Intel

------------------------------

Date: Thu,  4 Feb 93 09:25:15 EST
From: [e-mail]
Subject: Stacker Drive write-protected somehow
Keywords: stacker print windows

I was running windows 3.1 and tried to print to a laser printer.  It
came back and said - printer not connected - try again.  I did that and
then it said - very low on memory - close applications I did that and
then it said - Extremely low on memory and stayed hung.  I did a reset.

( By the way I have stacker installed - so I have aD drive.)

During the intial boot message it said D is write protected run scheck
/f which is a stacker command.

I ran scheck /f - it complained about a few files and then hung itself.

Now used the Norton utilities but it complains that the drive D is
write protected.

I did a chkdsk /v/f and it complained about some cross-links between
files and then some FAT-1 and FAT-2 were corrupt.

What can I do to atleast make the drive D read/write.  I know I can do
it all over again but that is the last resort.

Any help appreciated.

Thanks
Masoor Ramesh

------------------------------

Date: 27 Jan 93 19:41:49 GMT
From: Pete Gontier <[e-mail]>
Subject: SUMMARY: UNIX-style links under MS-DOS
Keywords: link DOS unix

I don't remember if I promised a summary, but I got such high-quality
repsonses that I figured I owed one.

My problem was this: due to #include file directory search limitations
of typical DOS C compilers (Borland, Microsoft), our highly
hierarchical source structure was giving us fits. We were trying to
specify too many directories for the compiler to search; the command
line was full and the relevant environment variable(s) was (were) full.

I was hoping that someone had hacked DOS to support UNIX-style links. I
could then create a directory and fill it with links to files deeply
nested in our hierarchy. I could then instruct the compiler to look in
only that one place for #include files.

It turns out that this is: 1) not necessary, 2) not possible. :-)

DOS apparently maintains in its directory a direct reference to a
file's location on disk. (UNIX uses an indirect reference.) If one were
to create a "link" under DOS, it would point to the right place on the
disk only until the file were modified. DOS would dutifully update the
file's "real" directory entry, and the link would get stale. The DOS
tool CHKDSK would eventually complain and try to "fix" the link.

Another possibility I imagined might work would be to patch DOS with a
TSR (terminate-and-stay-resident program). Several people wrote to tell
me this would be compatibility hell, in terms of both other hacks and
Windows, which doesn't necessarily go through official DOS file system
channels when it wants to mess with the file system.

A good suggestion, put foward by several people, was to use the DOS
SUBST or JOIN command in whatever way was appropriate. Apparently SUBST
lets you assign a drive letter to an arbitrary directory, which means I
could "alias" C:\FOO\BAR\BAZ\QUUX to Q:.  Specifying Q: to the compiler
would be a lot shorter than the pathname. Apparently JOIN is similar to
UNIX mount.

Another good suggestion, put forward by several more people, was to
create dummy header files in one directory. A file called "QUUX.H"
might contain

        #include "\FOO\BAR\BAZ\QUUX.H"

Several schemes were mentioned which allowed one to at least partially
automate the creation of these dummy header files, inlcuding using the
DIR /S command in various ways.

Thanks to all who responded.

P.S. Some people 1) suggested that the next version of DR DOS might
support links. 2) told me that they were working on a relatively safe
method for creating links under DOS. Keep your eyes and ears open for
both.

 Pete Gontier // EC Technology // [e-mail]

------------------------------

Date: 1 Feb 93 21:10:03 GMT
From: Douglas Pokorny <[e-mail]>
Subject: Undocumented config.sys params

Today I was busy browsing through the file io.sys from MS-DOS 5.0 and I
noticed two undocumented commands for config.sys.

The first is COMMENT, which appears to have the same effect as REM.

The second, however, is called MULTITRACK.  I have been unable to
figure out what this parameter specifies.

Does anyone out there in net-land have a clue as to what the multitrack
command does?

Thanks for any pointers!

-Douglas

   Douglas R. Pokorny
   [e-mail]
   CS major/Geisert Hall Resident
  Bradley   University    "The Harvard of the Midwest"

------------------------------

Date: 2 Feb 93 11:48:15 GMT
From: [e-mail]
Subject: Undocumented config.sys params

I found another one: 'SWITCHES=' which accept at least the next line

 SWITCHES=/k

According to some docs this means something like "Support for enhaced
keyboards" of which I concluded that <F11> and <F12> may now be
processed by INT 16h, AH=00h and 01h in stead of AH=10h or 11h.  But
this isn't true...

Rob Gerrits.

------------------------------

End of Info-IBMPC Digest V93 #24
********************************
-------