NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/ibm/pc/digest/195

Text File | 1992-12-29 | 25.6 KB | 712 lines

Path: sparky!uunet!zaphod.mps.ohio-state.edu!saimiri.primate.wisc.edu!ames!agate!ucbvax!WSMR-SIMTEL20.ARMY.MIL!Info-IBMPC
From: [e-mail] ("Info-IBMPC Digest")
Newsgroups: comp.sys.ibm.pc.digest
Subject: Info-IBMPC Digest V92 #207
Message-ID: <[e-mail]>
Date: 29 Dec 92 12:31:05 GMT
Sender: [e-mail]
Reply-To: [e-mail]
Organization: The Internet
Lines: 698
Approved: [e-mail]
X-Unparsable-Date: Sun, 27 Dec 92 23:08:05 GMT+1

Info-IBMPC Digest           Sun, 27 Dec 92       Volume 92 : Issue 207

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

Today's Topics:
                  32-bit programming using MASM 6.00b
                          ATI driver support!
                            CKermit - help!
                      Re: OS/2 2.0 32 bit drivers!
              Cry for Help: TCP/IP programming API wanted
                          Customizing EPM 5.51
           Detecting ANSI.SYS (was: Re: DOS text attributes)
                              DLL question
                           Help hook solution
            IBM TCP/IP: how to get my own address? (2 msgs)
                      keybinding in OS/2 gnuemacs
                    OS/2: leave it running?(2 msgs)
                 OS/2 libraries thread-safe ? (2 msgs)
                   This is strange, div doesn't work
                    where should SET name=thing go?

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: 16 Dec 92 22:37:57 GMT
From: Kai Uwe Rommel <[e-mail]>
Subject: 32-bit programming using MASM 6.00b

[e-mail] (The Rottweiler) writes:
>Is there anyone out there who has experience assembling 32-bit OS/2
>v2.0 programs using Microsoft's MASM 6.00b.  I thought that I could use
>the flat memory model but LINK386 chokes on the object code.  LINK386
>does not complain if I use the normal segmented model but the EXE
>created generates a 000E trap.

What probably happens is, that you call the *16-bit* DOS calls in your
program. The 32-bit ones are prefixed with Dos32 instead of Dos, i.e.
Dos32Write and so on. Working example:

----------------------------------------------------
.386
.model    flat
.stack    04000H

includelib doscalls.lib

.data

message    byte    13, 10, "Hello, world.", 13, 10

.data?

count   dword    ?

.code

extern    DOS32WRITE:proc
extern    DOS32EXIT:proc

start   proc

    push    offset count
    push    lengthof message
    push    offset message
    push    1
        call    DOS32WRITE

        push    27
        push    1
    call    DOS32EXIT

start    endp

    end    start
----------------------------------------------------

Kai Uwe Rommel

--
/* Kai Uwe Rommel                                      Muenchen, Germany *
 * [e-mail]                       Phone [phone] *
 * [e-mail]                  Fax [phone] */

DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be.                -Russell Williams

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

Date: 17 Dec 92 23:15:01 GMT
From: Ted Chen <[e-mail]>
Subject: ATI driver support!

[e-mail] (Mike Timbol) writes:
>[e-mail] (Scott Moore) writes:
>>The salesman at Comdex may have not been well informed, but I was
>>told that ATI is doing *ZIP* about ultra pro drivers for os/2 2.0, but
>>only distributing IBM written code. They were showing it off right next
>>to their brand new (ATI written) NT driver.
>>Scott

>On CompuServe, someone from ATI said they were working on Ultra Pro
>drivers and were targeting 2nd Quarter '93.  They were "thinking about"
>or "looking at" doing drivers for the VGA Wonder cards.  By the way, a
>great many people on CompuServe are very very pissed at ATI.
>
>     - Mike

For all you ATI Vantage/Ultra/8514/a/Ultra Pro/+ users, why not send
some email to ATI to voice your displeasure at their absence of drivers
for OS/2 2.0.

I believe their email address at CIS is

[e-mail]

Ted Chen   <[e-mail]>

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

Date: 17 Dec 92 07:57:35 GMT
From: Steve Lumos <[e-mail]>
Subject: CKermit - help!

[e-mail] (Greg A. Harris) writes:

>???? You cannot "connect" until you "dial". Look at ckermit.ini. Make
>sure it has your modem listed in 'set modem' and check the 'set port'.
>Then do 'dial 123-4567' to dial. Then do connect.  Read ckoker.doc
>(packaged in the ckermit 5A(188) files in pub/uploads) to find the
>procedure to automate the logon with scripts, once you get things
>working.

Note: I cannot figure out how to make it stop setting my port speed to
the connect speed reported by the modem. I want my com port to stay
locked at 57600, but CKermit adjusts it to 14400 when it sees the
CONNECT 14400 message. This is a real pain and I have to escape back
and reset the speed. To avoid having to do this, I go:

C-Kermit>set carrier off
C-Kermit>c

It doesn't complain then...

Steve Lumos - [e-mail]

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

Date: 18 Dec 92 07:32:03 GMT
From: "Sean P. Frigo UW-Madison SRC (608" <[e-mail]>,
Subject: Re: OS/2 2.0 32 bit drivers!

The following is an excerpt from an e-mail sent to me by ATI in
response to my request about OS/2 2.0 32 bit drivers:


From: ATI Support <[e-mail]>
Date:  12-17-92

As can found here in the ATI forum in CompuServe, or by contacting ATI
support, IBM has not yet released the Development Kit which allows us
to complete 32 bit video drivers for OS/2 (and you will not find any
other video board manufacturers with 32 bit video drivers on the
market). IBM has not even released their own 8514/A 32 bit driver yet!
Once we have the development kit, we will be able to complete and
release 32 bit drivers. Meanwhile, the current OS/2 drivers we supply
will work with the versions of OS/2 1.3x and 2.x, with the 16 bit
Graphics Engine.

Regards,

Allan Nelson,
ATI Customer Support>>>

(1)    I thought Trident had released 32 bit drivers.  If so, how
could they have done it w/out the Development Kit from IBM?  Or, is ATI
the party at fault, since the above is in error and the kit exists?

(2)    If the kit hasn't been released yet, when will it be?  Let's
hope it is soon!

Sean P. Frigo                  internet: [e-mail]
UW-Madison SRC and Department of Physics    bitnet:  frigo@wiscpsl
3731 Schneider Drive                         voice:  [phone]
Stoughton WI 53589-3097                        fax:  [phone]

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

Date: 16 Dec 92 17:48:49 GMT
From: Scott Abfalter <[e-mail]>
Subject: Cry for Help: TCP/IP programming API wanted
Keywords: MSDOS, TCP/IP, Sockets

Help:

I am going to be rewriting LAN software for my company and we need to
use TCP/IP and some sort of socket API.

We're not happy using FTP software's PC/TCP for DOS because the
programmers development kit forces you to replace the Microsoft system
include files with their own butchered version.

We cannot use Beame & Whitesides TCP/IP and socket library either.  We
must operate in a nonblocking mode and their socket library blocks on a
soclose() call if there is a physical break in communications.

I am currently looking into both Network Researches "Fusion for DOS"
and Novell's LAN WorkPlace Toolkit (for LAN WorkPlace for DOS) as a
replacement solution.

Has anyone out there reading this had experience with either of the two
mention packadges?  Can anyone reccommend any others?  I need help as
I've already bought two packadges only to find out their limitations
and am hesitant to buy any more until I know for sure that they are any
good.

_ANY_ advice on this would be _GREATLY_ appreciated!!!  Thanks!

Scott
Scott Allen Abfalter
Intellivoice Communications
[phone] xt. 661
[e-mail] _or_  [e-mail]

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

Date: 17 Dec 92 19:11:08 GMT
From: KUMARADAS JOSEPH CARL <[e-mail]>
Subject: Customizing EPM 5.51

[e-mail] (James Nicolson) writes:

>I am using EPM v5.51 from software.watson.ibm.com. (Its seems like a
>really good editor)

>When it comes to customizing it, I ran into a problem. Even without
>including my own .e files (mystuff.e etc.), the translator (etpm) complains
>about the .ex file being bigger than the allowed 64k. Ie. all I am doing is:
>  etpm epm
>using the macro files as supplied in epmmac.zip.
>
>Am I missing something?

You should add the WANT_EXTRA=1 (or something to that effect) to a
mycnf.e file.  The .ex files are for some reason limited to 64k eac.
The WANT_EXTRA will put the rest on a second file which must also be
created by compiling the extra.e macro file.

Carl.

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

Date: 17 Dec 92 17:28:49 GMT
From: GUNNAR HORRIGMO <[e-mail]>
Subject: Detecting ANSI.SYS (was: Re: DOS text attributes)

From: [e-mail] (Carl Harris)

>[e-mail] (Mikko H{nninen) writes:
>> I know I can detect ANSI driver by comparing an interrupt's and the CON
>> device's segment addresses (I think). But is this reliable? Are there any
>> other programs aside from ANSI that act as the CON device?
>
>The standard method for detecting the presence of the ANSI driver is to
>send a DSR (Device Status Report) sequence to the console.  If the
>driver is present, it will respond with a CPR (Cursor Position Report) via
>standard input.

I don't know what it really does, but there is an int 21 (?) ANSI.SYS
installation check.

  /                \   |Gunnar Horrigmo          |
/____________________\ |[e-mail]|

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

Date: 18 Dec 92 20:46:37 GMT
From: David Charlap <[e-mail]>
Subject: DLL question
Keywords: DLL library

[e-mail] (Deepak Dhamdhere) writes:
>I have an application that calls functions from ABC.DLL, those
>functions call routines from XYZ.DLL and those, in turn, call routines
>from the C library. This application starts a child process using
>DosExecPgm, which in turn, does the same thing. I have used
>llibcdll.lib to link all these programs and libraries.

Are you also using the compiler switches to ensure that DS!=SS and that
DS is always loaded on process entry.  I think these are in the keyword
EXPENTRY.  I believe that any functions you export to a DLL must be
declared with this.

>Very frequently, it generates a segementation violation. When I
>checked with Codeview, I found that the malloc() call fails because it
>tries to load a non-existent segment into DS.

It sounds like the DLL is (correctly) assuming that DS!=SS, and is
loading it, but the calling program isn't providing the segment.  Be
sure that the code and headers are using the EXPENTRY keyword for all
exported functions.

>Any clues to why is this happening ? I would like to know the correct
>way of compiling and linking ABC.DLL, XYZ.DLL and the applications.

In general, I don't like to call C run-time functions from DLL's, but
that's a different story.  Some compilers (like EMX/GCC) have the C
library functions in a DLL, so there's little linkage problems, but you
can't do that with MS-C.

  |)  David Charlap          | .signature confiscated by FBI due to
 /|_  [e-mail] | an ongoing investigation into the
((|,)                        | source of these .signature virusses
 ~|~

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

Date: 16 Dec 92 15:05:10 GMT
From: "Larry Salomon Jr." <[e-mail]>
Subject: Help hook solution

Some time ago, I posted a desperate plea for help with providing help
for message boxes via the help hook (the only possible way to do so).
I did everything according to the documentation to no avail; I could
not get the "Help" button to work.

Well, the documentation was wrong and has been since OS/2 1.2 (both
IBM's Programming Guide and MS's QuickHelp overviews are incorrect).
They state that, if you are going to use a help hook, it should be
installed PRIOR to creating the help instance, since it too installs a
help hook to perform its function.  However, if you assume for the
moment that it uses the WinSetHook() function to do so and look in the
docs for that, you'll see that the call installs the hook at the *head*
of the hook chain.

That means, for those who don't already see the problem :) , that if I
install A and the HM installs hook B afterwards, the hook chain is
B->A; but the HM never calls the next hook!

When I moved the WinSetHook() to after the WinAssociateHelpInstance()
call everything worked fine.

You would think that *someone* *somewhere* would have found this doc
error, but *AP*p*AR*ently not.  IBM, please fix this.

Cheers,
Q

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

Date: 16 Dec 92 22:34:03 GMT
From: Kai Uwe Rommel <[e-mail]>
Subject: IBM TCP/IP: how to get my own address????

If I use IBM's TCP/IP, how am I supposed to get the host name/address
of the local system? There is no gethostname() call and gethostid()
always returns -1. Could anyone PLEASE tell me how I can solve this
stupid problem? What else can I do (except perhaps calling sock_init())
before calling gehostid() to have it succeed?

Is it me that I don't see an overly simple solution or is the
programmer's kit of IBM's TCP/IP so bad?

Thanks,

/* Kai Uwe Rommel                                      Muenchen, Germany *
 * [e-mail]                       Phone [phone] *
 * [e-mail]                  Fax [phone] */

DOS ... is still a real mode only non-reentrant interrupt
handler, and always will be.                -Russell Williams

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

Date: 17 Dec 92 16:39:21 GMT
From: Oleg Vishnepolsky <[e-mail]>
Subject: Re: IBM TCP/IP: how to get my own address????

[e-mail] (Kai Uwe Rommel) writes:
>[... Text of Query deleted...]

You have to call sock_init() before calling gethostid().

Oleg Vishnepolsky

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

Date: 17 Dec 92 13:03:28 GMT
From: Jochen Bedersdorfer <[e-mail]>
Subject: keybinding in OS/2 gnuemacs

[e-mail] (Carolyn Rogoff David Rogoff) writes:

>   I've been using the OS/2 2.0 gnuemacs for a few weeks now.  I've
>used emacs and epoch on Suns for year and to me the best part of emacs
>is assigning function to keys.  I have tried with several people's
>hints to map the PC keyboard, but I haven't gotten anywhere.

>   I want to be able to do simple things like map the arrow keys to
>forward-char etc., page up/page down, and the 12 function keys.  Below
>is a part of my .emacs on the Sun.

If you have the port of Eberhard Mattes (I don`t know any other), there
should be a file em-keys.el (??? I am not shure, but `em` is okay).

There are most bindings for PC-Keyboards (Functionskeys, Arrowkeys
etc.).  That should do the trick !

BTW, anyone interested in having ALT-PAGEUP doing
scroll-other-screen-up (ALT-PAGEDOWN is doing scroll-other-screen-down)
?  If so, I`ll post the changings...

:)ochen

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

Date: 18 Dec 92 20:04:04 GMT
From: Barry R Solway <[e-mail]>
Subject: OS/2: leave it running?

>[e-mail] (Dave Serls) writes:

>  I'm wondering how many users keep their OS/2 2.0 machines running
>full-time; that is, 24 hours a day.  Is there any benefit gained,
>thereby; or, are shorter sessions less injurious to HD hardware.

    I've had OS2 2.0 loaded since August or so. I hardly ever  turn
it off, except sometimes  at night if I don't think I will be  using it
the next day, or when my roommates want to boot with Dos to play games.
Never had any problems and like another poster said, it's common belief
that the stress on the I.C. chips is greater during power on/off then
normal running wear and tear.

% banshee @brahms.udel.edu     %
% solway @freezer.cns.udel.edu %

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

Date: 18 Dec 92 16:28:06 GMT
From: Kevin Andrew Buhr <[e-mail]>
Subject: OS/2: leave it running?

[e-mail] (Dave Serls) writes:

>  I'm wondering how many users keep their OS/2 2.0 machines running
>full-time; that is, 24 hours a day.  Is there any benefit gained,
>thereby; or, are shorter sessions less injurious to HD hardware.

Many people claim that the heat-cool cycle of powering a computer on
and off is much harder on the "solid-state" components than leaving it
on all the time is on the hard drive.

Unless your hard drive is incredibly flaky, it should be safe to leave
it on pretty much all the time.  There is no contact between the head
and the platter, so the only "deterioration" in an idle (but spinning)
drive would be in the rotor mechanism.  I don't think this is a big
concern.

In conclusion, leaving your OS/2 station on is fine.  I would be sure
to check that the vents are clear and the fan is running, though.  ;)

Kevin <[e-mail]>

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

Date: 17 Dec 92 17:00:43 GMT
From: Jeff Urlwin <[e-mail]>
Subject: OS/2 libraries thread-safe ?

[e-mail] writes:
>[e-mail] (Ernst Kloecker) writes:

>>what precautions do I have to take when calling C-library functions from
>>different threads in one process ?

>What C library? I can only speek for Microsoft C 6.0. I not quite sure
>about IBM Cset/2 yet, but I think the answers are applicable for that
>library as well.
>
>There are (at least) two versions of the library - one "normal" and one
>thread safe.  In MSC you invoke the thread safe library with -MT.

When you compile with the option /Gm+ and link with the multithreaded
library, you should be OK.  You should use _beginthread() to start your
thread.  It sets up the correct behavior of the library routines.
(NOTE: if you use /Gm+ and have ICC call the linker for you, it will
grab the multithreaded libs for you...)

>>What happens to static variables like 'errno' ?
>
>No problem. errno is redefined with the preprocessor to a thread-safe
>function:
>  #define errno thread_safe_errno_function()
>or something like that.

errno is actually a function call with the CSet/2.  It will properly
deal with the multiple threads.  I forget, but I think it's defined as:

extern _Optlink int *_errno(void);
#define errno  (*_errno())

Don't quote me on this, but I know I've seen this somewhere...

>>Can I safely call '...printf()' from different threads ?

>Not quite sure, but I think so. printf/sprintf etc uses (in MSC) a
>static result array. This array is guarded with semaphores. However,
>there can be a small risk that the output from several threads are
>mixed with each other (but only one of them calls printf() of course).

Well sprintf shouldn't be a problem, because you supply the buffer.
(just don't call it with the same buffer...).  printf could either:
guard the use by semaphores or dynamically allocate the memory.  Either
way you *should* be OK with the call.  Where you might run into
problems is when looking at the info.  If your stdout (or your FILE) is
buffered in any way, you could be seeing some messed up stuff...or at
least the info will be interleaved...

If this is for debugging, let me tell you what I've done in the past
(on Transputers, where you have multiple threads AND multiple
processors -- non shared memory across the processors) is to have the
notion of a timestamp and do a fprintf from each thread with the
timestamp, thread id (and processor, in that case) and debugging
message.  Then you can have a program merge the info into one file,
based upon time.  So you might see.  in file 1: 1 In thread1 4 start
calculating pi 10 finished first approx

in file 2:
2 finished setup of thread 1
5 got user input
11 got finished pi...

etc.

It's pretty simple at this point to concatenate the files and sort them
by time...this way you can see what's really going on...somewhat
realtime.

You have to be careful, though, that you're not putting in too much
printing in one thread and changing the timing of the threads and how
they interact.  I've seen it happen most of the time where introducing
debugging printfs, etc actually "solves" the problem....you're in for a
fun hunt then!

>>Or are the only safe functions the OS-functions in 'bsedos.h' ?

>>Or are even those functions not completely thread-safe ?

>Not absolutly sure how they are implemented, but functions like
>strtok(), localtime(), gmtime() etc seems a bit dangerous - I guard
>them with a semaphore when I use them.

I agree.  It's better to be careful, until you can see somewhere that
they ARE re-entrant.  Maybe someone at IBM can tell us which calls are
re-entrant and which aren't.  I would have to assume (until I could
test further) that the Dos, Win, etc calls are re-entrant, but I would
check that...

>>Thanks for any info, Ernst.

>No problem. Hope it helped. Can someone with experience from Cset/2
>and emx tell how it's done there?

I hope someone who is more "in the know" than I am could continue this...

Does anyone have any neat tricks/techniques for debugging this stuff?
Maybe the fact that my background is more in parallel processing, I
don't see how people are using it here...maybe I go a little
overboard...

Jeff
[e-mail]

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

Date: 17 Dec 92 21:30:38 GMT
From: Bruce Kitchin <[e-mail]>
Subject: OS/2 libraries thread-safe ?

Ernst Kloecker ([e-mail]) wrote:

The C library has been pretty well handled by the other responses.  If
you compile properly with IBM C Set/2 (set the multithreaded compile
option) you should be completely safe except from your own
multithreaded errors (simultaneous access of shared globals without
semaphore protection).

: Or are the only safe functions the OS-functions in 'bsedos.h' ?
:
: Or are even those functions not completely thread-safe ?
:
All functions declared through including os2.h (includes bse*.h, pm*.h,
etc) are safe.  They are part of or attached to the operating system
which is designed for such problems.  They are not part of the C
library.  Again, you can get into trouble due to sharing your own
variables.  But I believe that every Dos, Win, Gpi, Mou, Kbd, Vio, etc
call is atomic to the extent that anything that it depends on in the
system (such as file buffers) are modified without the chance of
another thread getting in.  However, two DosWrite's in a row may be
split by a DosWRite from another thread.

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

Date: 18 Dec 92 14:48:24 GMT
From: Steve Madsen <[e-mail]>
Subject: This is strange, div doesn't work....

Michael Duffy ([e-mail]) wrote:
: The following code gives me a divide error:
:
:  mov  ax,0035h
:  mov  dx,01h
:  div  dx
:

    I'm not a genius at assembler, but after looking in my TASM 3.2
quick-ref, this is about the only thing I could come up with:

    What it appears is that you are doing a simple 16-bit divide.
As far as my manual is concerned, if you do a div instruction with a
16-bit operand (such as dx in your example), then it uses DX:AX as your
dividend.  This might be why you are having a problem, but it's only a
guess.

    You could try changing DX to DL and see if that works.  Since
you are assigned DX to what looks like a byte value anyway, this might
solve your problem.

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

Date: 18 Dec 92 16:51:10 GMT
From: Kevin Andrew Buhr <[e-mail]>
Subject: where should SET name=thing go?

In article <[e-mail]> [e-mail] (John
Calvert) writes:
>
>  What do you mean here "specific DOS"?

A VDM session:  this is a feature whereby it is possible to "boot" a
session from drive A and have it run just as if it was run on a normal
8088 machine.  In this way, you could boot an old version of DOS, if
you had a program that wasn't compatible with OS/2's version of DOS,
for example.  You could also run a program that required booting from a
drive, even a program that didn't use DOS, provided that program didn't
try to use any protected mode features.

In this case, of course, the "AUTOEXEC.BAT" that is run is the one on
the floppy disk, if any.

>  If CONFIG.SYS is for OS/2, and AUTOEXEC.BAT is for DOS, where is the
>  normal DOS CONFIG.SYS stuff?
>
>  Is this all contained in the Settings, Session, DOS Settings for each
>  application? What if I want to change some config setting for all my
>  DOS appls? Do I have to edit every Settings entry?

Yes, it is contained there.  You'll find the "FILES" and "BUFFERS" and
"DOS_DEVICE" settings, for example, replace their counterparts in the
DOS CONFIG.SYS.

If you'd like to change the settings for programs you create "from now
on", you can change the settings in the program template.  Then, when
you create a new program object, it will have the new defaults.  In the
CSD, there is a "DOS/Windows Settings" icon somewhere in the System
Setup folder.  I believe some settings can be given global values here.

>  This would be a very messy way do go.

Not particularly.  I think its a smart idea to have separate settings
for each program.  That way, changes to one program's settings won't
have adverse effects on another session.  Under DOS, I don't think I've
ever had application A *benefit* from a change I've made to the
CONFIG.SYS to get application B to run.  Usually, changes I make for
application A's sake cause problems.

There are exceptions, of course.  "DOS=HIGH,UMB" is something I want
for every application.  Luckily, OS/2 lets me put this line in the OS/2
"CONFIG.SYS" where it influences all the DOS sessions, if I remember
correctly.

Kevin <[e-mail]>

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

End of Info-IBMPC Digest V92 #207
*********************************
-------