OS/2 Shareware BBS: 15 Message/15-Message.zip/UU991113.zip/Uh991112.txt

Text File | 1999-11-15 | 153KB | 4,232 lines

                   comp.os.os2.programmer.misc      (Usenet)

                 Saturday, 06-Nov-1999 to Friday, 12-Nov-1999

+----------------------------------------------------------------------------+

From: [e-mail]                                     06-Nov-99 08:44:26
  To: All                                               06-Nov-99 05:25:28
Subj: EARN $1000 TO $5000 WEEKLY!!!  4932

From: [e-mail]

FINALLY!!!

A SIMPLE ONLINE SYSTEM FOR MAKING FAST, EASY, MONEY THAT LASTS !!!

A TOTAL NO-BRAINER THAT ANYONE IN THE WORLD CAN DO !!!

Go to: http://opportunity.valuenetusa.com/JL2836/

AND GET STARTED TODAY !!!







zpgcvnmuscpeoxdwbshcsjszolyetygsrixbhjmikbocsynzpmvxnrhlodtbzhblp

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: AT&T WorldNet Services (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                  06-Nov-99 13:50:12
  To: All                                               06-Nov-99 14:36:00
Subj: Re: Max file handles for processes

From: [e-mail] (Yuri Dario)

On Fri, 5 Nov 1999 08:32:50, Carsten Thorenz
<[e-mail]> wrote:

> Look at the value of "files=xxx" in your config.sys.


it should affect only DOS sessions, not OS/2 handles.

Bye,

    Yuri Dario

/*
 * member of TeamOS/2 - Italy
 * http://www.quasarbbs.com/yuri
 */

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: MC-link The World On Line (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                           06-Nov-99 21:24:04
  To: All                                               06-Nov-99 20:02:25
Subj: Re: !How get `font size` list inside WPS extension code ?

From: [e-mail] (Eric Olson)

On Fri, 5 Nov 1999 21:53:53, Peter Fitzsimons <[e-mail]> wrote:

> GpiQueryFonts(). This will show the screen fonts.  Run it like this "sf
> >log", then look at the file "log".
>
> [--- snip: sf.c ----]
>
> // compile: icc /Q /Smes /W3 /Kb+ /O sf.c /B"/pm:pm"

Hi,
 here is a hack if you would like the sample to work with gcc

add the following line:
#define INCL_DOS
before the line  #include <os2.h>

and in main after ----    long i, p --- add
    PTIB  thread_block;
    PPIB  process_block;

    DosGetInfoBlocks( &thread_block, &process_block );
    process_block->pib_ultype = 3;

You can then compile with
gcc -o sf.exe sf.c
and run in the same way
sf >log

Cheers,

Eric

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Sympatico (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                    07-Nov-99 03:58:06
  To: All                                               07-Nov-99 03:28:17
Subj: Re: Patch help

From: Peter Fitzsimons <[e-mail]>

John Poltorak wrote:
>
> I'm trying to build wget.exe by applying the patch from the OS/2 version
> to the original source, but I can't get patch (GNU Patch 2.5.4) to work.
>
> Can some help out with the syntax?
>
> I'm trying apply the patch using wget-1.5.3-os2.diff from c:\test\wget\os2
> to the source which is in c:\test\wget\wget-1.5.3\src.
>

Can't help you there, but I do have an os/2 wget.exe (1.4.5) if you want
it.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: @Home Network Canada (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                     07-Nov-99 10:50:22
  To: All                                               07-Nov-99 05:18:09
Subj: Killing the WPS

From: Juergen Dankoweit <[e-mail]>

Hello.

I have a great problem in killing the WPS:
I use a daemon-program to start the WPS. In this daemon I have thread
that starts
the WPS via DosStartSession() - which works great - and then waits
on DosReadQueue() until the WPS ends. I also use an exception-handler
that
reacts on DosKillProcess().
In this handler the program waits until the thread with DosReadQueue()
ends.

My problem is that DosKillProcess() cannot always kill the WPS.
Especially then
when I use the WPS (opening folders and so on).

Does anyone have an idea what to do that the WPS can be killed always?

I have an other question: How do I register fonts globally in the
system? Are there any API-calls?

Many thanks

Jürgen Dankoweit

=============================================
Juergen Dankoweit       TeamOS/2-Member #1086
URL: home.t-online.de/home/Juergen.Dankoweit
>> OS/2... it's cool men! <<

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: T-Online (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                        07-Nov-99 10:47:23
  To: All                                               07-Nov-99 10:20:14
Subj: Re: Patch help

From: [e-mail] (John Poltorak)

In <[e-mail]>, Peter Fitzsimons <[e-mail]> writes:
>John Poltorak wrote:
>>
>> I'm trying to build wget.exe by applying the patch from the OS/2 version
>> to the original source, but I can't get patch (GNU Patch 2.5.4) to work.
>>
>> Can some help out with the syntax?
>>
>> I'm trying apply the patch using wget-1.5.3-os2.diff from c:\test\wget\os2
>> to the source which is in c:\test\wget\wget-1.5.3\src.
>>
>
>Can't help you there, but I do have an os/2 wget.exe (1.4.5) if you want
>it.

It's OK Peter, I already have 1.5.3. It's just that one of the default
locations
for .wgetrc is C:\TCPIP\ETC, whereas I'd prefer to use %ETC%.

--
John

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Legend Internet Ltd (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                 07-Nov-99 14:11:16
  To: All                                               07-Nov-99 15:15:21
Subj: Re: Detecting MMX processor

From: [e-mail] (Martin Schuette)

[e-mail] (Ruediger Ihle) wrote  :

> How does an OS/2 app check, that it runs on an MMX-like
> processor in order to take advantage of some new instructions ?

By using CPUID and testing the appropriate bit in EAX.

--
Martin
"It is better to die on your feet than to live on your knees."

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Origin Line 1 Goes Here (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                  07-Nov-99 15:53:15
  To: All                                               07-Nov-99 15:15:21
Subj: Re: Max file handles for processes

From: [e-mail] (Yuri Dario)

Hi,

> From UNDOC.INF somewhere out on the net (Hobbes ?):
> > SHELLHANDLESINC= - This environment variable increments the number of file


that's worked. Thanks for help.

Bye,

    Yuri Dario

/*
 * member of TeamOS/2 - Italy
 * http://www.quasarbbs.com/yuri
 */

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: MC-link The World On Line (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                         04-Nov-99 22:00:18
  To: All                                               07-Nov-99 15:15:21
Subj: Re: Max file handles for processes

From: Hannes Hromadka <[e-mail]>


 Hi,

> E.g. simply running the following loop
>
>    i = 0;
>    do {
>       printf( "try %d\n", i);
>       fp = fopen( "dummy.txt", "r");
>       i++;
>    } while( fp);
>
> will open only 10 files when using gcc (without EMXOPT=-hxxx). With
> VAC++ the runtime allocates free handles when needed (probably calling
> DosSetMaxFH).
>
> There is a way to raise this limit with a system-wide change? I need
> it because I have a couple of programs running out of handles and I
> can't recompile them.

Try

SET EMXOPT=-c -n -h1024

this opens 1028 files before it stops on WSeB

Compiling this code with VaCPP seems to produce a program with no limit
on file handles.

I stopped the test at more than 9000 open files


It used a lot of memory:

Here is the output of Theseus/2


Memory Utilization for Process with PID = 0197, name = 'TEST':
    bytes      bytes    number  bytes      bytes    bytes
allocated  committed   present   each    present  swapped  description
 0000075C   0000075C         1   075C   0000075C 00000000  PTDA
 000002F4   000002F4         1   02F4   000002F4 00000000  TCB
 00001000   00001000         1   1000   00001000 00000000  TSD
 00010000   00009000         7   1000   00007000 00002000  LDT
 000001E0   000001E0       480   01E0   000001E0 00000000  Process Page
Directory
 00078000   00027000        39   1000   00027000 00000000  Page Tables
 05330000   018ED000       987   1000   003DB000 01130000  Accessible
Shared memory
 01360000   00021000        11   1000   0000B000 00000000  Originated
Shared memory
 02870000   0278A000      7311   1000   01C8F000 00977000  Private
memory

 00089C30   00031C30                    0002FC30 00002000  Total System
 01360000   00021000                    0000B000 00000000  Total Shared
originated
 02870000   0278A000                    01C8F000 00977000  Total Private
 --------   --------                    -------- --------
 03C59C30   027DCC30                    01CC9C30 00979000  Total
RAM/SWAPPER for this Process
    61799      40819                       29479     9700  (in Kbytes)
   60.351     39.863                      28.789    9.473  (in Mbytes)
< End of THESEUS3 (v 3.000.00) output @ 21:57:05 on 4.11.1999 >



----

General Information about the Process with PID = 0197, name = 'TEST':
PTDA address = FF1C52FC

Threads for this Process:
                                    ---- priority ----
 TID   Th_#        TCB        TSD  class  level actual  state
0001   007B   FA590574   F9C7A000     02     00   0001   0002  Blocked

Exit List:
  Class   RtnAddress  Description
   0010   FDFF:57B6   PMVIOP   #0001 (shared code)
   0010   1F5C1BE0    GRE2VMAN #0001 (shared code)
   0010   1E9845C8    PMMERGE  #0004 (shared code)
   0010   F40F:85E4   PMMERGE  #0002 (shared code)
   00B0   E027:3118   DOSCALL1 #0004 (shared code)
   00C0   E027:50F8   DOSCALL1 #0004 (shared code)
   0100   1E8E58D0    PMMERGE  #0004 (shared code)
   01A2   FDFF:56C6   PMVIOP   #0001 (shared code)
   01A5   1E984CCC    PMMERGE  #0004 (shared code)
   01AB   1E86D968    PMMERGE  #0004 (shared code)
   01AB   F407:16CA   PMMERGE  #0001 (shared code)
   01AB   1E887530    PMMERGE  #0004 (shared code)
   01AD   1F5C1BD0    GRE2VMAN #0001 (shared code)
   01B0   E027:3118   DOSCALL1 #0004 (shared code)
   01C0   E027:B674   DOSCALL1 #0004 (shared code)
   01C0   E027:5105   DOSCALL1 #0004 (shared code)
   01F0   1F784D88    VIDEOPMI #0002 (shared code)
   01FF   000140AC    TEST     #0001 (shared code)

Open Files (MaxFH=9128):
  ---- handles ---
  Process   System   Flags  File name // Flags...
     0000     004F    08    \DEV\CON // console
     0001     004F    08    \DEV\CON // console
     0002     004F    08    \DEV\CON // console
     0003     0147    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0004     006E    08    \DEV\KBD$ // console
     0005     0138    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0006     0132    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0007     0145    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0008     0043    00    \DEV\OEMHLP$ //
     0009     0146    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000A     017D    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000B     0041    00    \DEV\LANMSG$$ //
     000C     0143    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000D     0163    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000E     0172    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000F     014F    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0010     0186    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error



        Hannes


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Global Network Services - Remote Access Mail & Ne
(1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                         07-Nov-99 18:09:18
  To: All                                               07-Nov-99 15:15:21
Subj: Re: Max file handles for processes

From: Hannes Hromadka <[e-mail]>


 Hi,

> E.g. simply running the following loop
>
>    i = 0;
>    do {
>       printf( "try %d\n", i);
>       fp = fopen( "dummy.txt", "r");
>       i++;
>    } while( fp);
>
> will open only 10 files when using gcc (without EMXOPT=-hxxx). With
> VAC++ the runtime allocates free handles when needed (probably calling
> DosSetMaxFH).
>
> There is a way to raise this limit with a system-wide change? I need
> it because I have a couple of programs running out of handles and I
> can't recompile them.

Try

SET EMXOPT=-c -n -h1024

this opens 1028 files before it stops on WSeB

Compiling this code with VaCPP seems to produce a program with no limit
on file handles.

I stopped the test at more than 9000 open files


It used a lot of memory:

Here is the output of Theseus/2


Memory Utilization for Process with PID = 0197, name = 'TEST':
    bytes      bytes    number  bytes      bytes    bytes
allocated  committed   present   each    present  swapped  description
 0000075C   0000075C         1   075C   0000075C 00000000  PTDA
 000002F4   000002F4         1   02F4   000002F4 00000000  TCB
 00001000   00001000         1   1000   00001000 00000000  TSD
 00010000   00009000         7   1000   00007000 00002000  LDT
 000001E0   000001E0       480   01E0   000001E0 00000000  Process Page
Directory
 00078000   00027000        39   1000   00027000 00000000  Page Tables
 05330000   018ED000       987   1000   003DB000 01130000  Accessible
Shared memory
 01360000   00021000        11   1000   0000B000 00000000  Originated
Shared memory
 02870000   0278A000      7311   1000   01C8F000 00977000  Private
memory

 00089C30   00031C30                    0002FC30 00002000  Total System
 01360000   00021000                    0000B000 00000000  Total Shared
originated
 02870000   0278A000                    01C8F000 00977000  Total Private
 --------   --------                    -------- --------
 03C59C30   027DCC30                    01CC9C30 00979000  Total
RAM/SWAPPER for this Process
    61799      40819                       29479     9700  (in Kbytes)
   60.351     39.863                      28.789    9.473  (in Mbytes)
< End of THESEUS3 (v 3.000.00) output @ 21:57:05 on 4.11.1999 >



----

General Information about the Process with PID = 0197, name = 'TEST':
PTDA address = FF1C52FC

Threads for this Process:
                                    ---- priority ----
 TID   Th_#        TCB        TSD  class  level actual  state
0001   007B   FA590574   F9C7A000     02     00   0001   0002  Blocked

Exit List:
  Class   RtnAddress  Description
   0010   FDFF:57B6   PMVIOP   #0001 (shared code)
   0010   1F5C1BE0    GRE2VMAN #0001 (shared code)
   0010   1E9845C8    PMMERGE  #0004 (shared code)
   0010   F40F:85E4   PMMERGE  #0002 (shared code)
   00B0   E027:3118   DOSCALL1 #0004 (shared code)
   00C0   E027:50F8   DOSCALL1 #0004 (shared code)
   0100   1E8E58D0    PMMERGE  #0004 (shared code)
   01A2   FDFF:56C6   PMVIOP   #0001 (shared code)
   01A5   1E984CCC    PMMERGE  #0004 (shared code)
   01AB   1E86D968    PMMERGE  #0004 (shared code)
   01AB   F407:16CA   PMMERGE  #0001 (shared code)
   01AB   1E887530    PMMERGE  #0004 (shared code)
   01AD   1F5C1BD0    GRE2VMAN #0001 (shared code)
   01B0   E027:3118   DOSCALL1 #0004 (shared code)
   01C0   E027:B674   DOSCALL1 #0004 (shared code)
   01C0   E027:5105   DOSCALL1 #0004 (shared code)
   01F0   1F784D88    VIDEOPMI #0002 (shared code)
   01FF   000140AC    TEST     #0001 (shared code)

Open Files (MaxFH=9128):
  ---- handles ---
  Process   System   Flags  File name // Flags...
     0000     004F    08    \DEV\CON // console
     0001     004F    08    \DEV\CON // console
     0002     004F    08    \DEV\CON // console
     0003     0147    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0004     006E    08    \DEV\KBD$ // console
     0005     0138    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0006     0132    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0007     0145    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     0008     0043    00    \DEV\OEMHLP$ //
     0009     0146    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000A     017D    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000B     0041    00    \DEV\LANMSG$$ //
     000C     0143    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000D     0163    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000E     0172    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error
     000F     014F    41    E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inheritX-Mozilla-Status: 0009010     0186    41
E:\HANNES\PROGR\C\TEST-FILEH\DUMMY.TXT //
no_inherit fail_if_error



        Hannes

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Global Network Services - Remote Access Mail & Ne
(1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                               07-Nov-99 14:08:27
  To: All                                               07-Nov-99 15:15:22
Subj: Re: Detecting MMX processor

From: Marty <[e-mail]>

Martin Schuette wrote:
>
> [e-mail] (Ruediger Ihle) wrote  :
>
> > How does an OS/2 app check, that it runs on an MMX-like
> > processor in order to take advantage of some new instructions ?
>
> By using CPUID and testing the appropriate bit in EAX.

That only works on Pentium class machines or higher.  It may be an illegal
instruction on a 486 or less.

- Marty

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Time Warner Road Runner - Binghamton NY (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                          07-Nov-99 18:43:18
  To: All                                               07-Nov-99 21:28:08
Subj: Info: Java Media Framework 2.0 Beta 2

From: Timothy Sipples <[e-mail]>

Sun and IBM have released the Java Media Framework Version 2.0 Beta 2.  It
is available in a pure Java(TM) cross-platform version (compatible with OS/2
Warp).

Visit:

http://java.sun.com/products/java-media/jmf

for more information and/or to download.

What's most interesting about this release is the file formats supported for
playback, including:

- Macromedia Flash 2
- Apple Quicktime (with certain CODECs, such as Cinepak)
- MP2 and MP3 Audio
- many more

In other words, using the Java Media Framework it should be relatively easy
to create a "native" Flash plug-in for OS/2 Warp's Netscape Communicator.

Has anybody tried this out yet?

--
Timothy Sipples
IBM Network Computing Software
Chicago, Illinois
Web: http://www.satdirect.com/aviation

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: IBM Network Computing Software (Chicago) (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                 08-Nov-99 09:54:23
  To: All                                               08-Nov-99 05:18:18
Subj: Re: Max file handles for processes

From: Carsten Thorenz <[e-mail]>

Peter Fitzsimons wrote:
>
> Carsten Thorenz wrote:
>
> That's for DOS programs only.

Yuck, really.

Anyhow I don't know why I can open about 95 files right now.
I suggested it was because of the "files" entry ...

Bye, Carsten


--
Carsten Thorenz           Institut fuer Stroemungsmechanik und
                          elektronisches Rechnen im Bauwesen
[e-mail]
http://www.hydromech.uni-hannover.de/w3-pages-thorenz/thorenz.html

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: RRZN - Newsserver Test (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                              08-Nov-99 10:56:21
  To: All                                               08-Nov-99 10:31:26
Subj: Re: Detecting MMX processor

From: [e-mail] (Ruediger Ihle)

On Sun, 7 Nov 1999 19:08:55, Marty <[e-mail]> wrote:

> Martin Schuette wrote:
> >
> > [e-mail] (Ruediger Ihle) wrote  :
> >
> > > How does an OS/2 app check, that it runs on an MMX-like
> > > processor in order to take advantage of some new instructions ?
> >
> > By using CPUID and testing the appropriate bit in EAX.
>
> That only works on Pentium class machines or higher.  It may be an illegal
> instruction on a 486 or less.

That's what I was suspecting. To avoid additional CPU detection (and the
risk of failing to correctly accomplish this) the exception handler
method
seems to me most reasonable.


Thanks guys

--
Ruediger "Rudi" Ihle [S&T Systemtechnik GmbH, Germany]
http://www.s-t.de
Please remove all characters left of the "R" in my email address

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: S&T (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                   08-Nov-99 14:45:18
  To: All                                               08-Nov-99 20:06:28
Subj: TCP/IP 4.2 Routing table mbufs leak?

From: Boris Borissov <[e-mail]>

Hi everybody,
Is it a known problem: when a task is trying to reach a destination, but

can't do it, then frees and re-allocates a socket and tries again, each
attempt cause 2 additional mbufs (see netstat -m) allocated and never
freed?
Similar problem was fixed in IC18283, but I wonder if it was included
in any 86XXX.

Boris.



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Teklogix Inc. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                               08-Nov-99 20:43:29
  To: All                                               08-Nov-99 21:19:01
Subj: Re: WSeb and LDGW and NDS

From: Leonardo Pino Werlinger <[e-mail]>

There is a way to attach securyty using realms under WebSphere, at least for
Windows. The way you do it is you set Users, Groups and ACLs, after that you
use a resource to be protected that means a file or a CGI, servlet ...etc.

I don't know if you will be able to see the way Netware uses the security
but maybe you could simulate something like a realm under Netware and maybe
Websphere will list it, all of this under OS/2 of course.

Give it a try.


Leonardo Pino

Charles Christacopoulos escribió:

> Hi,
>
> I would appreciate any pointers, tips, ideas (whatever) to the
> following.
>
> We are primarily a Netware/Solaris house, apart from me being odd with
> OS/2.
> I run WSeB and Lotus Domino Go web server(s) to provide the www intranet
> at our institution.
>
> Without gettting into any detail, LDGW can call an external program to
> validate users when they try to get  www "protected" files.  I would
> like to "one day" have such an external program that would actually
> validate users against Netware's NDS tree (thus users would in effect
> use the same ID and password for Netware and for viewing files on the
> www).
>
> Where do I start looking for a solution?
> Will the LDAP kit that comes with WSeB allow me to do anything like it?
> Can it be done?
> Has anyone got it (we would be willing to pay :-) ?
>
> TIA.
> Regards
> Charles
>
> Remove REMOVE_ME to reply.
> -------------------------------------------------------------------
> Charles Christacopoulos, Secretary's Office, University of Dundee,
> Dundee DD1 4HN, (Scotland) United Kingdom.
> Tel: +44+(0)1382-344891. Fax: +44+(0)1382-201604.
> http://somis.ais.dundee.ac.uk/    (runs on OS/2)
> Scottish Search Maestro http://somis2.ais.dundee.ac.uk/ (runs on OS/2
> too)

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: DCC - Universidad de Chile (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                          09-Nov-99 00:36:16
  To: All                                               08-Nov-99 21:19:01
Subj: Re: Detecting MMX processor

From: [e-mail] (Mads Orbesen Troest)

On Mon, 8 Nov 1999 10:56:42, [e-mail] (Ruediger Ihle)
wrote:

> That's what I was suspecting. To avoid additional CPU detection (and the
> risk of failing to correctly accomplish this) the exception handler

.. or simply make sure it is a >= Pentium processor before using the
cpuid method. MMX extensions do not exist for processors below
Pentium.

   These were the incoherent ramblings of ...
      ... /\/\\ads Orbesen Troest <[e-mail]>
            [http://www.sprog.auc.dk/~motr96]

(Please remove NEVERMORE from address when replying via email...)

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: SIRIUS Cybernetics (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                               08-Nov-99 20:58:20
  To: All                                               09-Nov-99 03:31:28
Subj: Re: Detecting MMX processor

From: Marty <[e-mail]>

Mads Orbesen Troest wrote:
>
> On Mon, 8 Nov 1999 10:56:42, [e-mail] (Ruediger Ihle)
> wrote:
>
> > That's what I was suspecting. To avoid additional CPU detection (and the
> > risk of failing to correctly accomplish this) the exception handler
>
> .. or simply make sure it is a >= Pentium processor before using the
> cpuid method. MMX extensions do not exist for processors below
> Pentium.

Not good enough, as some Pentium's don't recognize the instruction either.

- Marty

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Time Warner Road Runner - Binghamton NY (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                           09-Nov-99 12:42:00
  To: All                                               09-Nov-99 15:59:29
Subj: Re: VAC++ debugger storage monitor: how to search for specific data?

From: Jerry Stuckle <[e-mail]>

Arie,

Sorry, you can't search for specific data - I assume part of the reason
could be that memory is not necessarily contiguous in OS/2, even with
virtual addresses.

A trick I've used quite often is to set a pointer to the data I want to
monitor, then stop when the pointer is set.  This will give me the
address of the data, and I can then set a breakpoint on the change.

Arie Kazachin wrote:
>
> Hello!
>
> I'm attempting to run some program from the debugger found in
> VAC++ 3.0. In the "storage" monitor window, there is no option
> to search for a specific data, there is only address which I can
> enter for the window to scroll to. I need to find some known data
> (a string) and to set a breakpoint when it'll be changed. But I don't
> know, how to find an address of a known data: I can't find such a
> trivial option as "search for ..." that is found in many other debuggers.
> It's almost unthinkable that such a trivial option doesn't exists in
> VAC++ debugger. Maybe I'm missing something obvious?
>
> THANKS IN ADVANCE FOR ANY HELP ! ! !
>
******************************************************************************
> *   Arie Kazachin, Israel, e-mail: [e-mail]
*
>
******************************************************************************
> NOTE: before replying, leave only letters in my domain-name. Sorry, SPAM
trap.

--

=======================================================
To reply, delete the "x" from my email address

Jerry Stuckle
[e-mail]
JDS Computer Training Corp.
Sun Certified Java Programmer
VisualAge/Java Certified Advanced Technical Expert
VisualAge/C++ Certified Developer

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

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: JDS Computer Training Corp. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                      09-Nov-99 21:58:28
  To: All                                               09-Nov-99 20:25:15
Subj: SYS_DLLS and superclassing native controls

From: [e-mail] (Kevin)

I have a massive PM application with hundreds and hundreds of entry
fields. It is used on 21 inch montiors and users are complaining that
they can't see the entry field cursor on the large screens.
Subclassing entry fields is not an option in this environment. So I
thought I could superclass WC_ENTRYFIELD. I have created a DLL with an
initialisation routine that attempts to get the class info for
WC_ENTRYFIELD, store the address of the window proc and register a
CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it
receives the focus it can call the original WC_ENTRYFIELD wnd proc and
then create a new cursor that is more visible.

I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called).
The DLL loads and executes its initialisation. WinQueryClassInfo gets
TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
CS_PUBLIC gets FALSE. But after re-booting, any window with an entry
field traps. This tends to indicate that my wndproc is being called,
even though I got FALSE on the register. I wonder if the address
returned by WinQueryClassInfo is valid in all the other processes.

I believe from a search on DEJA that Rich Walsh has done this kind of
thing before. What I want to do is register my own wndproc for all
WC_ENTRYFIELD controls created and create a different cursor every
time an entry field gets the focus. What am I doing wrong?

Anything that requires all of the definitions of entry fields to be
changed is out of the question. If this isn't possible, I have to tell
the users to just live with it. If they want something else they
should call IBM OS/2 support!

I thought I was the only one still doing real OS/2 apps. I think I
know OS/2 pretty well. Rich, where are you? Please help...

Kevin Hawkins
PMSC onsite at Norwich Union in the UK
email: kevin at munot dot demon dot co dot uk.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Organization (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                    10-Nov-99 06:30:14
  To: All                                               10-Nov-99 05:30:18
Subj: Re: SYS_DLLS and superclassing native controls

From: Peter Fitzsimons <[e-mail]>

> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called).
> The DLL loads and executes its initialisation. WinQueryClassInfo gets
> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
> CS_PUBLIC gets FALSE. But after re-booting, any window with an entry
> field traps. This tends to indicate that my wndproc is being called,

How are you defining your data segments?  ie:"single shared", or what?

If you are loading anything (like a pointer/icon/bmp) you have to do it
for each app, which probably forces you do use an "initinstance multiple
nonshared" dll. So keep your data segment size down, and try to compile
/Rn.

I have code that subclasses the titlebar for every app with a sys_dll
"load once" entry.  It installs a msg hook, that looks for WM_CREATE
messages;  if the window is what I'm looking for, then I subclass it
"live". I'm a resource freak and the thought of "loadperprocess" and
"mutliple data" offended me at the time (1995, when I only had 24mb of
memory I think :).

Anyway, you're welcome to the code if you like.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: @Home Network Canada (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                     10-Nov-99 01:42:28
  To: All                                               10-Nov-99 10:29:14
Subj: WSeb and LDGW and NDS

From: [e-mail] (Vitus Jensen)

Hello Charles,

08.11.99 18:18, Charles Christacopoulos wrote a message to All :

 CC> I would appreciate any pointers, tips, ideas (whatever) to the
 CC> following.

 CC> We are primarily a Netware/Solaris house, apart from me being odd
 CC> with OS/2. I run WSeB and Lotus Domino Go web server(s) to
 CC> provide the www intranet at our institution.

 CC> Without gettting into any detail, LDGW can call an external
 CC> program to validate users when they try to get  www "protected"
 CC> files.  I would like to "one day" have such an external program
 CC> that would actually validate users against Netware's NDS tree
 CC> (thus users would in effect use the same ID and password for
 CC> Netware and for viewing files on the www).

 CC> Where do I start looking for a solution?

To write a program using the NDS for user validation you need the "Client SDK"
for OS/2 from Novell.  When I was doing such things (over 4 years ago) it was
sold, documentation only readable from WinOS/2.  There are a lot of 16 bit
functions you may call but to decide which function is used for what purpose
isn't simple.


 CC> Will the LDAP kit that comes with WSeB allow me to do anything
 CC> like it? Can it be done? Has anyone got it (we would be willing
 CC> to pay :-) ?

If you can manage to synchronize the LAN Server domain with the NDS you would
have a much simpler task: just call Net[32]UserValidate().
The server (and requester?) package contains INF, header, lib and samples how
to do this.  Look for x:\IBMLAN\NETSRC (don't remember the installation
option,
sorry).

C-x C-s
    Vitus

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Fido.DE domain gateway (Moving Bits e.V. / IN e.V
(1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                        10-Nov-99 10:45:22
  To: All                                               10-Nov-99 10:29:14
Subj: XCPT_SPACE_ACCESS Violation in DOSCALL1

From: [e-mail] (Mike Fry)

Could someone help me with this entry from the POPUPLOG.OS2 on a Warp 4,
FP12 machine?

Unfortunately, I didn't write the offending program (it's in 16-bit
COBOL of all things), but I have written a lot of underlying routines
(Watcom C) that live in DLLs, along with various service programs. All C
code is 32-bit. The DLLs used by the COBOL program have equivalent
16-bit and 32-bit entry points (Watcom is good for this sort of thunking
<g>).

11-05-1999  14:30:29  SYS3171  PID 0029  TID 0001  Slot 0053
C:\DLRC\MCHOTB04.EXE
c0000005
1bfa0184
P1=00000008  P2=00000134  P3=XXXXXXXX  P4=XXXXXXXX
EAX=00000079  EBX=000047fc  ECX=0000001f  EDX=0000eb84
ESI=00002590  EDI=00002800
DS=a447  DSACC=00f3  DSLIM=000047ff
ES=a44f  ESACC=00f3  ESLIM=00001aef
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=dfd7:00000184  CSACC=00df  CSLIM=0000dc08
SS:ESP=0137:000009f2  SSACC=****  SSLIM=********
EBP=000009f2  FLG=00012202

DOSCALL1.DLL 0003:00000184

I don't really understand the SYS3171 - exception within exception. As
far as I know, my DLLs don't use exception handlers apart from what the
CRT installs. Is it possible to determine which routine in DOSCALL1.DLL
this trap actually occurred in?

My suspicion is that this is some kind of application-caused memory
leak. Examination of the C & COBOL source code shows that tiled memory
objects are being allocated by DosAllocSharedMem in one of my service
EXEs and passed to the COBOL program, via a queue, after doing a
DosGiveSharedMem to give the COBOL program read/write permission. The
service EXE then does a DosFreeMem.

At some stage on the COBOL side, an apparently unnecessary DosGetSeg
(16-bit remember) is being done. I say unnecessary because the program
already has read/write access to the object thru the DosGiveSharedMem
call. I can only find a single DosFreeSeg in the COBOL code. Am I right
in thinking that OS/2 is unable to 'physically' free the memory objects
because of a non-zero reference count? And that over time, OS/2 will
actually 'run out' of memory?

To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION.
According to my toolkit headers, the P1 value indicates
XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually run
out of selectors because of the unnecessary DosGetSeg (missing
DosFreeSeg), then I would have expected to find P1 to indicate
XCPT_LIMIT_ACCESS.

I can't find any explanation in my documentation of what these two
access violation codes mean in real terms. Can anybody explain the
difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my
description of the memory object usage make sense in terms of the trap
information that I have supplied?

Thanks for listening,
MIKE FRY
mailto:[e-mail]

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: UUNET Internet Africa (1:109/42)

+----------------------------------------------------------------------------+

From: yourself@127.0.0.1                                10-Nov-99 11:00:29
  To: All                                               10-Nov-99 10:29:15
Subj: Re: SYS_DLLS and superclassing native controls

From: yourself@127.0.0.1 (Rich Walsh)

On Tue, 9 Nov 1999 21:58:56, [e-mail] (Kevin) wrote:

> I have a massive PM application with hundreds and hundreds of entry
> fields. It is used on 21 inch montiors and users are complaining that
> they can't see the entry field cursor on the large screens.
> Subclassing entry fields is not an option in this environment. So I
> thought I could superclass WC_ENTRYFIELD. I have created a DLL with an
> initialisation routine that attempts to get the class info for
> WC_ENTRYFIELD, store the address of the window proc and register a
> CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it
> receives the focus it can call the original WC_ENTRYFIELD wnd proc and
> then create a new cursor that is more visible.
>
> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called).
> The DLL loads and executes its initialisation. WinQueryClassInfo gets
> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
> CS_PUBLIC gets FALSE. But after re-booting, any window with an entry
> field traps. This tends to indicate that my wndproc is being called,
> even though I got FALSE on the register. I wonder if the address
> returned by WinQueryClassInfo is valid in all the other processes.
>
>I believe from a search on DEJA that Rich Walsh has done this kind of
>thing before. What I want to do is register my own wndproc for all
>WC_ENTRYFIELD controls created and create a different cursor every
>time an entry field gets the focus. What am I doing wrong?

Do you really want to modify every entryfield in the system or just the
ones in your app?  Either way, you'll have to deal with odd side-effects
your code may have on, say, read-only comboboxes (i.e. no visible cursor).

For a global replacement, the superclassing code in your DLL should only
be executed once:  the first time it's called, when it's operating in the
shell process.  You shouldn't have to change any flags.  You can store
the original PFN in global memory because it's valid in all PM processes.

The traps you're getting now probably occur because the DLL's instance
data hasn't been initialized properly (are you using INITINSTANCE and
DATA MULTIPLE NONSHARED ?).  Since your needs are so minimal, you may
not even need a per-process data segment except to satisfy your compiler.
If so, try shedding the runtime environment - or even the runtime itself
(YMMV).

BTW...  are you aware that the function you've exported as ordinal 1
gets called every time your dll is loaded into a new process?

For a process-specific solution, forget most everything I just said :-)
AFAIK, you can't reregister a CS_PUBLIC class for a particular process.

Instead, you can try this strategy (one of several that come to mind):
identify whether the message that causes an e/f to create its cursor
is posted or sent.  Then use either an InputHook or a SendMsgHook on
your *own* message queue (HMQ_CURRENT) to intercept it.  This will
let you put the code in your exe, avoid sub- or superclassing, and
generally limit the damage.  (IMHO, this is a good solution when
you're messing with your own app, and a lousy solution when you're
messing other people's.)


   == == almost usable email address:  rlwalshATpacket.net == ==
___________________________________________________________________

                |             - DragText v3.1 -
Rich Walsh      |  A Distinctly Different Desktop Enhancement
Ft Myers, FL    |  New!  Pickup & Drop for text, and more...
                |  http://www.usacomputers.net/personal/rlwalsh/
___________________________________________________________________

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: http://extra.newsguy.com (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                      10-Nov-99 21:28:20
  To: All                                               10-Nov-99 20:03:07
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail] (Kevin)

On 10 Nov 1999 11:00:58 GMT, yourself@127.0.0.1 (Rich Walsh) wrote:

>On Tue, 9 Nov 1999 21:58:56, [e-mail] (Kevin) wrote:
>
>> I have a massive PM application with hundreds and hundreds of entry
>> fields. It is used on 21 inch montiors and users are complaining that
>> they can't see the entry field cursor on the large screens.
>> Subclassing entry fields is not an option in this environment. So I
>> thought I could superclass WC_ENTRYFIELD. I have created a DLL with an
>> initialisation routine that attempts to get the class info for
>> WC_ENTRYFIELD, store the address of the window proc and register a
>> CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it
>> receives the focus it can call the original WC_ENTRYFIELD wnd proc and
>> then create a new cursor that is more visible.
>>
>> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's called).
>> The DLL loads and executes its initialisation. WinQueryClassInfo gets
>> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
>> CS_PUBLIC gets FALSE. But after re-booting, any window with an entry
>> field traps. This tends to indicate that my wndproc is being called,
>> even though I got FALSE on the register. I wonder if the address
>> returned by WinQueryClassInfo is valid in all the other processes.
>>
>>I believe from a search on DEJA that Rich Walsh has done this kind of
>>thing before. What I want to do is register my own wndproc for all
>>WC_ENTRYFIELD controls created and create a different cursor every
>>time an entry field gets the focus. What am I doing wrong?
>
>Do you really want to modify every entryfield in the system or just the
>ones in your app?  Either way, you'll have to deal with odd side-effects
>your code may have on, say, read-only comboboxes (i.e. no visible cursor).

Users would be happy with every entryfield in the system. This is the
only app being used, so I don't have to worry about other people's
apps. Didn't thing about the comboboxes, but their entryfields are
easy enough to distinguish from ordinary ones.

>For a global replacement, the superclassing code in your DLL should only
>be executed once:  the first time it's called, when it's operating in the
>shell process.  You shouldn't have to change any flags.  You can store
>the original PFN in global memory because it's valid in all PM processes.

Thanks for clearing that up.

The WinRegisterClass call returns FALSE when I try to register with
all the parameters from WinGetClassInfo the same except for PFNWP.
Haven't done WinGetLastError here yet as I was trying Peter
Fitzsimmons' idea today. Don't know if I believe the return value
though because I was getting traps on anything that created an
entryfield.

>The traps you're getting now probably occur because the DLL's instance
>data hasn't been initialized properly (are you using INITINSTANCE and
>DATA MULTIPLE NONSHARED ?).  Since your needs are so minimal, you may
>not even need a per-process data segment except to satisfy your compiler.
>If so, try shedding the runtime environment - or even the runtime itself
>(YMMV).

I had INITINSTANCE and DATA MULTIPLE NONSHARED in all cases.
Currently using the runtime for fprintf for debugging, but will
probably not use it in the end.

>BTW...  are you aware that the function you've exported as ordinal 1
>gets called every time your dll is loaded into a new process?
Hmmm. I am exporting by names, but the first export is my
initialisation function. This function does get called on load as my
fprintf shows.

>For a process-specific solution, forget most everything I just said :-)
>AFAIK, you can't reregister a CS_PUBLIC class for a particular process.

That is correct according to the documentation.

>Instead, you can try this strategy (one of several that come to mind):
>identify whether the message that causes an e/f to create its cursor
>is posted or sent.  Then use either an InputHook or a SendMsgHook on
>your *own* message queue (HMQ_CURRENT) to intercept it.  This will
>let you put the code in your exe, avoid sub- or superclassing, and
>generally limit the damage.  (IMHO, this is a good solution when
>you're messing with your own app, and a lousy solution when you're
>messing other people's.)

Have been playing with hooks today. Wanted to used Peter's suggestion
to use a hook to catch all WM_CREATE messages and subclass
WC_ENTRYFIELDS. Have tried all the 'message' type hooks, but so far
none seem to get WM_CREATE messages. Hoping Peter's code will help
here.

The private hook is interesting. The entryfield has to create/destroy
the cursor on one of the activate/focuschange type messages. I will
look into that more tomorrow.

Thanks,
Kevin

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Organization (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                               10-Nov-99 14:15:02
  To: All                                               10-Nov-99 20:03:07
Subj: Re: XCPT_SPACE_ACCESS Violation in DOSCALL1

From: Dave Blaschke <[e-mail]>


Mike Fry wrote:

Ahh, Mike Fry, the man who asked me to add yet another executable to the
OS2TRACE package.  Because it's you I'll try and answer correctly for a
change ;-)

> Could someone help me with this entry from the POPUPLOG.OS2 on a Warp 4,
> FP12 machine?
>
> Unfortunately, I didn't write the offending program (it's in 16-bit
> COBOL of all things), but I have written a lot of underlying routines
> (Watcom C) that live in DLLs, along with various service programs. All C
> code is 32-bit. The DLLs used by the COBOL program have equivalent
> 16-bit and 32-bit entry points (Watcom is good for this sort of thunking
> <g>).
>
> 11-05-1999  14:30:29  SYS3171  PID 0029  TID 0001  Slot 0053
> C:\DLRC\MCHOTB04.EXE
> c0000005
> 1bfa0184
> P1=00000008  P2=00000134  P3=XXXXXXXX  P4=XXXXXXXX
> EAX=00000079  EBX=000047fc  ECX=0000001f  EDX=0000eb84
> ESI=00002590  EDI=00002800
> DS=a447  DSACC=00f3  DSLIM=000047ff
> ES=a44f  ESACC=00f3  ESLIM=00001aef
> FS=150b  FSACC=00f3  FSLIM=00000030
> GS=0000  GSACC=****  GSLIM=********
> CS:EIP=dfd7:00000184  CSACC=00df  CSLIM=0000dc08
> SS:ESP=0137:000009f2  SSACC=****  SSLIM=********
> EBP=000009f2  FLG=00012202
>
> DOSCALL1.DLL 0003:00000184
>
> I don't really understand the SYS3171 - exception within exception. As
> far as I know, my DLLs don't use exception handlers apart from what the
> CRT installs. Is it possible to determine which routine in DOSCALL1.DLL
> this trap actually occurred in?

SYS3171 simply means that a thread did not have enough stack space available
to dispatch an exception.  When an exception occurs, the OS/2 kernel
attempts to "push" an exception report record and context record, along with
some other goodies,  on top of the user's stack for the ring 3 exception
dispatcher: if this fails, a SYS3171 will result.  This does not necessarily
mean that an exception occurred within a handler.

As for the routine, you can't really figure it out without the DOSCALL1.MAP
file or some debug tools that can extract the info from DOSCALL1.SYM.  In
this case, DOSCALL1 object 3 offset 184 is within the DOSSEMWAIT API on
FP12.

>
>
> My suspicion is that this is some kind of application-caused memory
> leak. Examination of the C & COBOL source code shows that tiled memory
> objects are being allocated by DosAllocSharedMem in one of my service
> EXEs and passed to the COBOL program, via a queue, after doing a
> DosGiveSharedMem to give the COBOL program read/write permission. The
> service EXE then does a DosFreeMem.
>
> At some stage on the COBOL side, an apparently unnecessary DosGetSeg
> (16-bit remember) is being done. I say unnecessary because the program
> already has read/write access to the object thru the DosGiveSharedMem
> call. I can only find a single DosFreeSeg in the COBOL code. Am I right
> in thinking that OS/2 is unable to 'physically' free the memory objects
> because of a non-zero reference count? And that over time, OS/2 will
> actually 'run out' of memory?
>
> To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION.
> According to my toolkit headers, the P1 value indicates
> XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually run
> out of selectors because of the unnecessary DosGetSeg (missing
> DosFreeSeg), then I would have expected to find P1 to indicate
> XCPT_LIMIT_ACCESS.
>
> I can't find any explanation in my documentation of what these two
> access violation codes mean in real terms. Can anybody explain the
> difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my
> description of the memory object usage make sense in terms of the trap
> information that I have supplied?

Both indicate that a trap C occurred.  If P1 == XCPT_SPACE_ACCESS, then the
trap C  occurred with a non-zero error code and P2 = this error code.  If P1
== XCPT_LIMIT_ACCESS, then the trap C occurred with a zero error code and P2
= XCPT_DATA_UNKNOWN.  The following is from the Intel programmer's
reference, where stack fault refers to trap C:

<CITE>
A stack fault is generated under two conditions:

* As a result of a limit violation in any operation which refers to the SS
register.  This includes stack-oriented instructions such as POP, PUSH,
ENTER, and LEAVE, as well as other memory
references which implicitly use the stack (for example, MOV AX,[BP+6]).  The
ENTER instruction generates this exception when there is too little space
for allocating local variables.

* When attempting to load the SS register with a descriptor which is marked
segment-not-present but is otherwise valid.  This can occur in a task
switch, a CALL instruction ro a different privilege level, a return to a
different privilege level, an LSS instruction, or a MOV or POP instruction
to the SS register.

When the processor detects a stack exception, it pushes an error code onto
the stack of the exception handler.  If the exception is due to a
not-present stack segment or to overflow of the new stack during an
interlevel CALL, the error code contains a selector to the segment which
caused the exception (the exception handler can test the present bit in the
descriptor to determine which exception occurred); otherwise, the error code
is 0.
</CITE>

>
>
> Thanks for listening,
> MIKE FRY
> mailto:[e-mail]



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: IBM Austin (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                               11-Nov-99 01:47:16
  To: All                                               10-Nov-99 20:03:07
Subj: WSeb and LDGW and NDS

From: [e-mail]

From: [e-mail] (Vitus Jensen)

Hello Charles,

08.11.99 18:18, Charles Christacopoulos wrote a message to All :

 CC> I would appreciate any pointers, tips, ideas (whatever) to the
 CC> following.

 CC> We are primarily a Netware/Solaris house, apart from me being
 odd
 CC> with OS/2. I run WSeB and Lotus Domino Go web server(s) to
 CC> provide the www intranet at our institution.

 CC> Without gettting into any detail, LDGW can call an external
 CC> program to validate users when they try to get  www "protected"
 CC> files.  I would like to "one day" have such an external program
 CC> that would actually validate users against Netware's NDS tree
 CC> (thus users would in effect use the same ID and password for
 CC> Netware and for viewing files on the www).

 CC> Where do I start looking for a solution?

To write a program using the NDS for user validation you need the
 "Client SDK"
for OS/2 from Novell.  When I was doing such things (over 4 years
 ago) it was
sold, documentation only readable from WinOS/2.  There are a lot of
 16 bit
functions you may call but to decide which function is used for what
 purpose
isn't simple.


 CC> Will the LDAP kit that comes with WSeB allow me to do anything
 CC> like it? Can it be done? Has anyone got it (we would be willing
 CC> to pay :-) ?

If you can manage to synchronize the LAN Server domain with the NDS
 you would
have a much simpler task: just call Net[32]UserValidate().
The server (and requester?) package contains INF, header, lib and
 samples how
to do this.  Look for x:\IBMLAN\NETSRC (don't remember the
 installation option,
sorry).

C-x C-s
    Vitus


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                   11-Nov-99 01:47:17
  To: All                                               10-Nov-99 20:03:07
Subj: XCPT_SPACE_ACCESS Violation in DOSCALL1

From: [e-mail]

From: [e-mail] (Mike Fry)

Could someone help me with this entry from the POPUPLOG.OS2 on a Warp
 4,
FP12 machine?

Unfortunately, I didn't write the offending program (it's in 16-bit
COBOL of all things), but I have written a lot of underlying routines

(Watcom C) that live in DLLs, along with various service programs.
 All C
code is 32-bit. The DLLs used by the COBOL program have equivalent
16-bit and 32-bit entry points (Watcom is good for this sort of
 thunking
<g>).

11-05-1999  14:30:29  SYS3171  PID 0029  TID 0001  Slot 0053
C:\DLRC\MCHOTB04.EXE
c0000005
1bfa0184
P1=00000008  P2=00000134  P3=XXXXXXXX  P4=XXXXXXXX
EAX=00000079  EBX=000047fc  ECX=0000001f  EDX=0000eb84
ESI=00002590  EDI=00002800
DS=a447  DSACC=00f3  DSLIM=000047ff
ES=a44f  ESACC=00f3  ESLIM=00001aef
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=dfd7:00000184  CSACC=00df  CSLIM=0000dc08
SS:ESP=0137:000009f2  SSACC=****  SSLIM=********
EBP=000009f2  FLG=00012202

DOSCALL1.DLL 0003:00000184

I don't really understand the SYS3171 - exception within exception.
 As
far as I know, my DLLs don't use exception handlers apart from what
 the
CRT installs. Is it possible to determine which routine in
 DOSCALL1.DLL
this trap actually occurred in?

My suspicion is that this is some kind of application-caused memory
leak. Examination of the C & COBOL source code shows that tiled
 memory
objects are being allocated by DosAllocSharedMem in one of my service

EXEs and passed to the COBOL program, via a queue, after doing a
DosGiveSharedMem to give the COBOL program read/write permission. The

service EXE then does a DosFreeMem.

At some stage on the COBOL side, an apparently unnecessary DosGetSeg
(16-bit remember) is being done. I say unnecessary because the
 program
already has read/write access to the object thru the DosGiveSharedMem

call. I can only find a single DosFreeSeg in the COBOL code. Am I
 right
in thinking that OS/2 is unable to 'physically' free the memory
 objects
because of a non-zero reference count? And that over time, OS/2 will
actually 'run out' of memory?

To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION.
According to my toolkit headers, the P1 value indicates
XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually
 run
out of selectors because of the unnecessary DosGetSeg (missing
DosFreeSeg), then I would have expected to find P1 to indicate
XCPT_LIMIT_ACCESS.

I can't find any explanation in my documentation of what these two
access violation codes mean in real terms. Can anybody explain the
difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my
description of the memory object usage make sense in terms of the
 trap
information that I have supplied?

Thanks for listening,
MIKE FRY
mailto:[e-mail]



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                 11-Nov-99 01:47:17
  To: All                                               10-Nov-99 20:03:07
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail]

From: yourself@127.0.0.1 (Rich Walsh)

On Tue, 9 Nov 1999 21:58:56, [e-mail] (Kevin)
 wrote:

> I have a massive PM application with hundreds and hundreds of entry
> fields. It is used on 21 inch montiors and users are complaining
 that
> they can't see the entry field cursor on the large screens.
> Subclassing entry fields is not an option in this environment. So I
> thought I could superclass WC_ENTRYFIELD. I have created a DLL with
 an
> initialisation routine that attempts to get the class info for
> WC_ENTRYFIELD, store the address of the window proc and register a
> CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when
 it
> receives the focus it can call the original WC_ENTRYFIELD wnd proc
 and
> then create a new cursor that is more visible.
>
> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's
 called).
> The DLL loads and executes its initialisation. WinQueryClassInfo
 gets
> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
> CS_PUBLIC gets FALSE. But after re-booting, any window with an
 entry
> field traps. This tends to indicate that my wndproc is being
 called,
> even though I got FALSE on the register. I wonder if the address
> returned by WinQueryClassInfo is valid in all the other processes.
>
>I believe from a search on DEJA that Rich Walsh has done this kind
 of
>thing before. What I want to do is register my own wndproc for all
>WC_ENTRYFIELD controls created and create a different cursor every
>time an entry field gets the focus. What am I doing wrong?

Do you really want to modify every entryfield in the system or just
 the
ones in your app?  Either way, you'll have to deal with odd
 side-effects
your code may have on, say, read-only comboboxes (i.e. no visible
 cursor).

For a global replacement, the superclassing code in your DLL should
 only
be executed once:  the first time it's called, when it's operating in
 the
shell process.  You shouldn't have to change any flags.  You can
 store
the original PFN in global memory because it's valid in all PM
 processes.

The traps you're getting now probably occur because the DLL's
 instance
data hasn't been initialized properly (are you using INITINSTANCE and
DATA MULTIPLE NONSHARED ?).  Since your needs are so minimal, you may
not even need a per-process data segment except to satisfy your
 compiler.
If so, try shedding the runtime environment - or even the runtime
 itself
(YMMV).

BTW...  are you aware that the function you've exported as ordinal 1
gets called every time your dll is loaded into a new process?

For a process-specific solution, forget most everything I just said
 :-)
AFAIK, you can't reregister a CS_PUBLIC class for a particular
 process.

Instead, you can try this strategy (one of several that come to
 mind):
identify whether the message that causes an e/f to create its cursor
is posted or sent.  Then use either an InputHook or a SendMsgHook on
your *own* message queue (HMQ_CURRENT) to intercept it.  This will
let you put the code in your exe, avoid sub- or superclassing, and
generally limit the damage.  (IMHO, this is a good solution when
you're messing with your own app, and a lousy solution when you're
messing other people's.)


   == == almost usable email address:  rlwalshATpacket.net == ==
___________________________________________________________________

                |             - DragText v3.1 -
Rich Walsh      |  A Distinctly Different Desktop Enhancement
Ft Myers, FL    |  New!  Pickup & Drop for text, and more...
                |  http://www.usacomputers.net/personal/rlwalsh/
___________________________________________________________________



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                   11-Nov-99 01:47:17
  To: All                                               10-Nov-99 20:03:07
Subj: USE or SPY any distant PC via LAN/INTERNET

From: [e-mail]

From: "Crowsort" <[e-mail]>

USE or SPY any distant PC via LAN/INTERNET

How YOU can Hack Windows 95-98-NT... in seconds!
And use or spy any PC via a LAN or the Internet... as if you were
 there!

Platforms concerned:
--------------------
=> Windows 95/98
=> Windows NT Workstation/Server 3.5, 3.51 and 4.0
=> Windows 2000

Whether you are a rookie or a seasoned hacker, there are times where
you want to do something RAPIDLY.

Some of us worked a lot to enhance password cracking but we have to
recognize that if passwords have been carefully chosen, it still
 takes a
lot of TIME.

Others are using well-known security holes in NT but we also have to
recognize that the ways to use those security breaches are not easy
and it also takes TIME to understand and to implement them.

There is a way to get all the passwords of *any* version of Windows
INSTANTLY. There is a way to control a distant machine 'as if you
 were
there'.

Netbus and BO2K were good attempts, I used them for months, but
 despite of
what their authors said, using it every day is difficult and
 frustrating
enough to
disgust lazy guys like me... the fact that I cannot see the distant
 screen
in
real-time is really frustrating!

A friend demonstrated me RA.

RA (Remote-Anything) is THE solution you were looking for: it shows
 in
real-time the distant desktop (like PC-Anywhere and other MB-based
commercial products) BUT the server (the program you install on the
 PC
you want to control) is **80 KB** long...

You can install it remotely by using the buffer overflows of Outlook
 Express
or IE4 or simply by sending it as an Email attachment!

Better than that: once installed, it does not show in the Task-List,
 can't
be discovered or killed with CTRL-ALT-DEL!

Once you poisoned PCs on a LAN, no need to remember which ones: RA
is able to find automatically available PCs and displays IP addresses
 and
DNS Names! Just click on one of them to be connected!

And it is so fast that you can see any animation playing on the
 distant PC
in real-time!

All this from one unique tool... Damned, I got it!
____________________________________________________

Here are some of the functions I picked-up from RA's Doc:

o Connect to a new desktop: opens the Connection Dialog Box which
 allows you
to open a
  new window on a new Desktop (you can watch multiple Desktops at a
 time).

o Monitor only: will toggle the passive-monitoring and active-control
 modes
(active
  monitoring allows you to type keys and move the mouse on the
 distant PC
while passive
  monitoring will only allow you to watch only).

o Full screen: will enter the full-screen mode. You can exit it by
 typing
CTRL+ESC and
  then right-clicking the Master's task bar icon to come back to the
windowed mode.

o Remove wallpaper on distant desktop: is useful to minimize the
 amount of
data sent
  over the network. It always speedups a connection.

o Start Screen Saver: is useful when you want to leave the desktop
 with a
screensaver
  running: when Remote-Anything moves the mouse cursor on a Slave
 desktop,
it stops
  the screensaver if it was running. With this option, you can
 immediately
run the
  screensaver (use this option with the keyboard shortcut to avoid
 moving
the mouse
  in active mode or switch to passive monitoring to activate this
 menu
option with
  the mouse). If the screensaver is password protected, this is a way
 to
lock the
  distant PC.

o Play a Sound: will make a sound being played on the distant PC.
 Usually it
is
  'ding.wav' but it can be any sound the distant PC registered as the
default sound.

o Send commands: will display a Dialog Box equivalent to the
 Start/Run
command of
  Windows 95.

o Get Passwords of distant PC: get all the network passwords, the
screensaver password,
  and the Applications passwords Windows has been asked to remember.

o Lockup distant PC: Hangs the distant PC which will need to be
 restarted
manually.

o Reboot distant PC: will immediately send the order to reboot to the
distant PC, this
  will disconnect you from this Desktop but you can reconnect once
 the
distant Windows
  session is active again.

o Shut Down distant PC: will shut down the distant PC if it supports
 shut
down. You
  will be disconnected.
_____________________________________________________

o How does it work?
  -----------------
It is as simple as using Windows 98 itself: move the mouse, type
 keys, the
distant PC will do everything you want! It works over LANs and the
 Internet!

o Where can I get it?
  -------------------
At the moment, you can get it from:

http://www.twd-industries.com

You'll have to pay a small fee to the authors to get RA. I can tell
 you that
it's worth the price: I simply did things I would never have been
 able to
do without it.
If you have access to a local network, RA will allow you to do
 whatever
you want! This tool is so easy to use that every hacker will want it.

The more you wait, the less what you can do with it will remain a
 secret!
But as time goes, I guess it will be available from a lot of other
 places.

Have fun!

   ººººººº
  ºº ººº ºº
º   ~   ~   º
@<ñ>"<ñ>@
  (       ~      )
    \  'v=v'   /    The Crowsort is back.
     |\____/|
_____________________________________________________








--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                           11-Nov-99 01:47:17
  To: All                                               10-Nov-99 20:03:07
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail]

From: Peter Fitzsimons <[e-mail]>

> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's
 called).
> The DLL loads and executes its initialisation. WinQueryClassInfo
 gets
> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
> CS_PUBLIC gets FALSE. But after re-booting, any window with an
 entry
> field traps. This tends to indicate that my wndproc is being
 called,

How are you defining your data segments?  ie:"single shared", or
 what?

If you are loading anything (like a pointer/icon/bmp) you have to do
 it
for each app, which probably forces you do use an "initinstance
 multiple
nonshared" dll. So keep your data segment size down, and try to
 compile
/Rn.

I have code that subclasses the titlebar for every app with a sys_dll
"load once" entry.  It installs a msg hook, that looks for WM_CREATE
messages;  if the window is what I'm looking for, then I subclass it
"live". I'm a resource freak and the thought of "loadperprocess" and
"mutliple data" offended me at the time (1995, when I only had 24mb
 of
memory I think :).

Anyway, you're welcome to the code if you like.


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: ariek@attglobal3.141592653589793...               10-Nov-99 23:24:17
  To: All                                               10-Nov-99 21:35:27
Subj: Re: VAC++ debugger storage monitor: how to search for specific data?

Message sender: [e-mail]

From: [e-mail] (Arie Kazachin)

In message <[e-mail]> - Tue, 09 Nov 1999 12:42:01
-0500Jerry Stuckle <[e-mail]> writes:
>
>Arie,
>
>Sorry, you can't search for specific data - I assume part of the reason
>could be that memory is not necessarily contiguous in OS/2, even with
>virtual addresses.
>
>A trick I've used quite often is to set a pointer to the data I want to
>monitor, then stop when the pointer is set.  This will give me the
>address of the data, and I can then set a breakpoint on the change.
>

Thanks, Jerry.

However, this trick only works when debugging a program you write.
When attempting to do this with already existing executable (and no sources),
it seems I'll have to let go on tha ability to search for data (unless
some developing/debugging utilities can do this).

Regards,
******************************************************************************
*   Arie Kazachin, Israel, e-mail: [e-mail] *
******************************************************************************
NOTE: before replying, leave only letters in my domain-name. Sorry, SPAM trap.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Unspecified Organization (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                            10-Nov-99 19:03:05
  To: All                                               10-Nov-99 21:35:27
Subj: sys/param.h and in.h on other systems

From: Joe Heafner <[e-mail]>

Hi.

I have some software that was designed to work under EMX, DJGPP, and
other systems equipped with gcc. It also compiles under VC++ on Win
systems. The programs make use of the sys/param.h and in.h header files.
When I attempt to compile the code under MingW32 (the Win32 port of gcc
2.9) the compiler complains about not being able to find these header
files.

Can anyone tell me the header files I should use under MingW23 to
compile these programs?

Someone else also told me that these particular header files are not
part of the ANSI/ISO C standard. All I know is that ever compiler/system
I've tested my software on apparently has these files and experiences no
problems. The only compiler to have a problem so far is MingW32. If
these files are not ANSI compliant, what are the appropriate ANSI header
files to use? The software, I belive (I didn't write this particular
part), uses these header files for functions needed to check and, if
necessary, change byte ordering (big endian vs. little endian) in
certain situations.


            Thanks,
--

                        -- Joe Heafner

Joe Heafner, Astronomy and Physics Instructor. Work:[phone] x4246
my surname with my first initial at interpath dot com
http://home.interpath.com/heafnerj/

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Interpath Communications, Inc. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                    11-Nov-99 09:28:11
  To: All                                               11-Nov-99 10:44:24
Subj: Re: sys/param.h and in.h on other systems

From: [e-mail] (Bob Eager)

On Thu, 11 Nov 1999 00:03:10, Joe Heafner <[e-mail]>
wrote:

> I have some software that was designed to work under EMX, DJGPP, and
> other systems equipped with gcc. It also compiles under VC++ on Win
> systems. The programs make use of the sys/param.h and in.h header files.
> When I attempt to compile the code under MingW32 (the Win32 port of gcc
> 2.9) the compiler complains about not being able to find these header
> files.

Where did you get the header files for the other compilers? If in a
toolkit, then if MingW32 can't find them you probably have it looking
in the wrong place.

> Can anyone tell me the header files I should use under MingW23 to
> compile these programs?

The same ones you used for the others.

> Someone else also told me that these particular header files are not
> part of the ANSI/ISO C standard. All I know is that ever compiler/system
> I've tested my software on apparently has these files and experiences no
> problems.

That's right. These headers are non-ANSI. The sys\param.h is
essentially a kernel configuration file on UNIX systems. The
occasional constant in there escapes for use by programs. The in.h (in
netinet\in.h on my system) contains networking stuff.

> The only compiler to have a problem so far is MingW32.

Sounds like the setup.

> If
> these files are not ANSI compliant, what are the appropriate ANSI header
> files to use?

There aren't.

> The software, I belive (I didn't write this particular
> part), uses these header files for functions needed to check and, if
> necessary, change byte ordering (big endian vs. little endian) in
> certain situations.

I can believe that the files you mention contain these functions. But
they aren't part of ANSI. Saying that you've seen them on every system
so far doesn' MAKE then suddnly ANSI.

I repeat, I think the set of headers you're using with the compiler is
incomplete. Or its INCLUDE environment variable isn't picking up the
toolkit directory.
--
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570, 9556*2,
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Tavi Systems (1:109/42)

+----------------------------------------------------------------------------+

From: yourself@127.0.0.1                                11-Nov-99 09:32:24
  To: All                                               11-Nov-99 10:44:24
Subj: Re: SYS_DLLS and superclassing native controls

From: yourself@127.0.0.1 (Rich Walsh)

On Wed, 10 Nov 1999 21:28:40, [e-mail] (Kevin) wrote:
> On 10 Nov 1999 11:00:58 GMT, yourself@127.0.0.1 (Rich Walsh) wrote:
> >On Tue, 9 Nov 1999 21:58:56, [e-mail] (Kevin) wrote:
> >
> >> I have a massive PM application with hundreds and hundreds of entry
> >> fields. It is used on 21 inch montiors and users are complaining that
> >> they can't see the entry field cursor on the large screens.
> >> Subclassing entry fields is not an option in this environment. So I
> >> thought I could superclass WC_ENTRYFIELD.
[big snip]
> >Instead, you can try this strategy (one of several that come to mind):
> >identify whether the message that causes an e/f to create its cursor
> >is posted or sent.  Then use either an InputHook or a SendMsgHook on
> >your *own* message queue (HMQ_CURRENT) to intercept it.  This will
> >let you put the code in your exe, avoid sub- or superclassing, and
> >generally limit the damage.  (IMHO, this is a good solution when
> >you're messing with your own app, and a lousy solution when you're
> >messing other people's.)
>
> Have been playing with hooks today. Wanted to used Peter's suggestion
> to use a hook to catch all WM_CREATE messages and subclass
> WC_ENTRYFIELDS. Have tried all the 'message' type hooks, but so far
> none seem to get WM_CREATE messages. Hoping Peter's code will help
> here.
>
> The private hook is interesting. The entryfield has to create/destroy
> the cursor on one of the activate/focuschange type messages. I will
> look into that more tomorrow.

DragText v1.x used the method Peter described (minus the SYS_DLLS
entry).  It had a flaw that you may consider a feature.  Comboboxes
and spinbuttons create entryfields which your code subclasses and
their code then re-subclasses.  They don't bother saving your PFNWP
and have their subprocs call the class's base window procedure instead
of yours.  Unless you subclass these controls too (as DT did), your
code will never be called when the entryfield is part of another
control.

You can do this entirely within your own app by installing a HK_SENDMSG
for each thread that creates entryfields (probably only the first).
This should eliminate access violations and let you retain your
C runtime.  Like IBM, you'll have to decide whether to discard each
window's PFNWP and use the class's default.

FWIW...  After I posted my earlier suggestion, I realized it won't
work if you have to use a HK_SENDMSG.  You want to create a cursor
after an e/f has handled a particular message but this hook gives
you no way to do so and no way to keep the message from being passed
on (with a HK_INPUT, your hook could dispatch the message itself,
do its thing on return, then terminate further processing).
Sorry 'bout that...


   == == almost usable email address:  rlwalshATpacket.net == ==
___________________________________________________________________

                |             - DragText v3.1 -
Rich Walsh      |  A Distinctly Different Desktop Enhancement
Ft Myers, FL    |  New!  Pickup & Drop for text, and more...
                |  http://www.usacomputers.net/personal/rlwalsh/
___________________________________________________________________

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: http://extra.newsguy.com (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                        11-Nov-99 12:52:16
  To: All                                               11-Nov-99 10:44:24
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail] (Bob Plyler)

In <[e-mail]>, [e-mail] (Kevin)
writes:
>I have a massive PM application with hundreds and hundreds of entry
>fields. It is used on 21 inch montiors and users are complaining that
>they can't see the entry field cursor on the large screens.
>Subclassing entry fields is not an option in this environment. So I
>thought I could superclass WC_ENTRYFIELD. I have created a DLL with an
>initialisation routine that attempts to get the class info for
>WC_ENTRYFIELD, store the address of the window proc and register a
>CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it
>receives the focus it can call the original WC_ENTRYFIELD wnd proc and
>then create a new cursor that is more visible.

Simple question.  Why not just replace the Cursors?
You can replace them with system supplied cursors in
the Mouse settings.  You can modify these cursors via ICONEDIT

Bob Plyler

IBM 3890/XP Engineering  (not an official IBM spokesperson)

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: IBM Global Services, South, RTP, NC, US (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                  11-Nov-99 13:09:13
  To: All                                               11-Nov-99 14:39:01
Subj: Problems when handling WM_PAINT in a second thread

From: [e-mail]

In a graphics application I am passing all WM_PAINT messages on to a
worker thread ("object window") for doing the real painting because it
takes some time to complete and I do not want to block the program
entirely. The user can issue e.g. a "zoom in" command while the graphics
is still being drawn and the response is immediate: Stop the first
repaint and start a new one with everything enlarged, etc. Works so far
very nicely.

However, a problem arises when I want to resize the window: It happens
frequently that the size just "jumps" to something completely wrong,
e.g. width zero or so. It only happens if the "move whole windows"
option is turned on, i.e. resizing means a whole avalanche of WM_PAINT
messages are arriving and competing with each other. I found a way to
handle this, with partial success, trying to set a flag "don't repaint"
while a resize action is on the way. In most cases this prevents the
strange "jumping resize", but still not always. OTOH sometimes the final
repaint doesn't seem to work and has to be forced somehow manually.

There is a certain chance that the problem even has something to do with
the multiple desktop feature of OD which I am running (v1.52
"professional").

QUESTION:

Does anybody see an entirely different setup for achieving the
responsiveness I want while long repaints are going on without running
into the problems I got?

Greetings and thanks for any hints,

Cornelis Bockemⁿhl

e-mail: [e-mail]
author of "PmAs - Astronomy for the Presentation Manager"
at http://www.datacomm.ch/cobo


Sent via Deja.com http://www.deja.com/
Before you buy.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Deja.com - Before you buy. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                           11-Nov-99 09:21:22
  To: All                                               11-Nov-99 14:39:02
Subj: Re: Problems when handling WM_PAINT in a second thread

From: Jerry Stuckle <[e-mail]>

I've done a lot with painting like this - especially things which take a
long time like changing the sizes of bitmaps.

I've found the easiest way to do it is to do your painting to a memory
PS.  Then when you get the WM_PAINT messages, just BitBlt the memPS to
the window PS.

[e-mail] wrote:
>
> In a graphics application I am passing all WM_PAINT messages on to a
> worker thread ("object window") for doing the real painting because it
> takes some time to complete and I do not want to block the program
> entirely. The user can issue e.g. a "zoom in" command while the graphics
> is still being drawn and the response is immediate: Stop the first
> repaint and start a new one with everything enlarged, etc. Works so far
> very nicely.
>
> However, a problem arises when I want to resize the window: It happens
> frequently that the size just "jumps" to something completely wrong,
> e.g. width zero or so. It only happens if the "move whole windows"
> option is turned on, i.e. resizing means a whole avalanche of WM_PAINT
> messages are arriving and competing with each other. I found a way to
> handle this, with partial success, trying to set a flag "don't repaint"
> while a resize action is on the way. In most cases this prevents the
> strange "jumping resize", but still not always. OTOH sometimes the final
> repaint doesn't seem to work and has to be forced somehow manually.
>
> There is a certain chance that the problem even has something to do with
> the multiple desktop feature of OD which I am running (v1.52
> "professional").
>
> QUESTION:
>
> Does anybody see an entirely different setup for achieving the
> responsiveness I want while long repaints are going on without running
> into the problems I got?
>
> Greetings and thanks for any hints,
>
> Cornelis Bockemühl
>
> e-mail: [e-mail]
> author of "PmAs - Astronomy for the Presentation Manager"
> at http://www.datacomm.ch/cobo
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--

=======================================================
To reply, delete the "x" from my email address

Jerry Stuckle
[e-mail]
JDS Computer Training Corp.
Sun Certified Java Programmer
VisualAge/Java Certified Advanced Technical Expert
VisualAge/C++ Certified Developer

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

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: JDS Computer Training Corp. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                  11-Nov-99 16:02:17
  To: All                                               11-Nov-99 14:39:02
Subj: Re: Problems when handling WM_PAINT in a second thread

From: [e-mail]

In article <[e-mail]>,
  [e-mail] wrote:
> I've done a lot with painting like this - especially things which take
a
> long time like changing the sizes of bitmaps.
>
> I've found the easiest way to do it is to do your painting to a memory
> PS.  Then when you get the WM_PAINT messages, just BitBlt the memPS to
> the window PS.

Hmm, could be worth a try. However I see one disadvantage: The user
doesn't see the image as it is being drawed. Sometimes you see e.g. the
first outline, see that it is too small and immediately zoom in, etc.
This viewing might be of less interest for bitmaps...

But if the procedure solves the problem...

Or maybe with a modification: The "object window" draws into a memory PS
and from time to time sends a message to the main thread telling it to
copy the current image to the screen... (??!)

Cornelis Bockemⁿhl <[e-mail]>

> [e-mail] wrote:
> >
> > In a graphics application I am passing all WM_PAINT messages on to a
> > worker thread ("object window") for doing the real painting because
it
> > takes some time to complete and I do not want to block the program
> > entirely. The user can issue e.g. a "zoom in" command while the
graphics
> > is still being drawn and the response is immediate: Stop the first
> > repaint and start a new one with everything enlarged, etc. Works so
far
> > very nicely.
> >
> > However, a problem arises when I want to resize the window: It
happens
> > frequently that the size just "jumps" to something completely wrong,
> > e.g. width zero or so. It only happens if the "move whole windows"
> > option is turned on, i.e. resizing means a whole avalanche of
WM_PAINT
> > messages are arriving and competing with each other. I found a way
to
> > handle this, with partial success, trying to set a flag "don't
repaint"
> > while a resize action is on the way. In most cases this prevents the
> > strange "jumping resize", but still not always. OTOH sometimes the
final
> > repaint doesn't seem to work and has to be forced somehow manually.
> >
> > There is a certain chance that the problem even has something to do
with
> > the multiple desktop feature of OD which I am running (v1.52
> > "professional").
> >
> > QUESTION:
> >
> > Does anybody see an entirely different setup for achieving the
> > responsiveness I want while long repaints are going on without
running
> > into the problems I got?
> >
> > Greetings and thanks for any hints,
> >
> > Cornelis Bockemⁿhl
> >
> > e-mail: [e-mail]
> > author of "PmAs - Astronomy for the Presentation Manager"
> > at http://www.datacomm.ch/cobo
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> --
>
> =======================================================
> To reply, delete the "x" from my email address
>
> Jerry Stuckle
> [e-mail]
> JDS Computer Training Corp.
> Sun Certified Java Programmer
> VisualAge/Java Certified Advanced Technical Expert
> VisualAge/C++ Certified Developer
>
> =======================================================
>


Sent via Deja.com http://www.deja.com/
Before you buy.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Deja.com - Before you buy. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                               12-Nov-99 01:45:29
  To: All                                               11-Nov-99 16:48:03
Subj: Re: USE or SPY any distant PC via LAN/INTERNET

From: [e-mail]

From: [e-mail] (Lorne Sunley)

On Wed, 10 Nov 1999 16:41:16, "Crowsort" <[e-mail]>
wrote:

> USE or SPY any distant PC via LAN/INTERNET
>
> How YOU can Hack Windows 95-98-NT... in seconds!
> And use or spy any PC via a LAN or the Internet... as if you were
 there!
>
> Platforms concerned:
> --------------------
> => Windows 95/98
> => Windows NT Workstation/Server 3.5, 3.51 and 4.0
> => Windows 2000

Yet another reason to resist the wiles of Microsoft.

If Outlook doesn't get you, something like this will

Lorne Sunley



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                     12-Nov-99 01:46:00
  To: All                                               11-Nov-99 16:48:03
Subj: Get Noticed!!

From: [e-mail]

From: [e-mail]

http:/www.mightybiz.com



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                           12-Nov-99 01:46:00
  To: All                                               11-Nov-99 16:48:03
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail]

From: [e-mail]

From: Peter Fitzsimons <[e-mail]>

> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's
 called).
> The DLL loads and executes its initialisation. WinQueryClassInfo
 gets
> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
> CS_PUBLIC gets FALSE. But after re-booting, any window with an
 entry
> field traps. This tends to indicate that my wndproc is being
 called,

How are you defining your data segments?  ie:"single shared", or
 what?

If you are loading anything (like a pointer/icon/bmp) you have to do
 it
for each app, which probably forces you do use an "initinstance
 multiple
nonshared" dll. So keep your data segment size down, and try to
 compile
/Rn.

I have code that subclasses the titlebar for every app with a sys_dll
"load once" entry.  It installs a msg hook, that looks for WM_CREATE
messages;  if the window is what I'm looking for, then I subclass it
"live". I'm a resource freak and the thought of "loadperprocess" and
"mutliple data" offended me at the time (1995, when I only had 24mb
 of
memory I think :).

Anyway, you're welcome to the code if you like.




--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                               12-Nov-99 01:46:00
  To: All                                               11-Nov-99 16:48:03
Subj: WSeb and LDGW and NDS

From: [e-mail]

From: [e-mail]

From: [e-mail] (Vitus Jensen)

Hello Charles,

08.11.99 18:18, Charles Christacopoulos wrote a message to All :

 CC> I would appreciate any pointers, tips, ideas (whatever) to the
 CC> following.

 CC> We are primarily a Netware/Solaris house, apart from me being
 odd
 CC> with OS/2. I run WSeB and Lotus Domino Go web server(s) to
 CC> provide the www intranet at our institution.

 CC> Without gettting into any detail, LDGW can call an external
 CC> program to validate users when they try to get  www "protected"
 CC> files.  I would like to "one day" have such an external program
 CC> that would actually validate users against Netware's NDS tree
 CC> (thus users would in effect use the same ID and password for
 CC> Netware and for viewing files on the www).

 CC> Where do I start looking for a solution?

To write a program using the NDS for user validation you need the
 "Client SDK"
for OS/2 from Novell.  When I was doing such things (over 4 years
 ago) it was
sold, documentation only readable from WinOS/2.  There are a lot of
 16 bit
functions you may call but to decide which function is used for what
 purpose
isn't simple.


 CC> Will the LDAP kit that comes with WSeB allow me to do anything
 CC> like it? Can it be done? Has anyone got it (we would be willing
 CC> to pay :-) ?

If you can manage to synchronize the LAN Server domain with the NDS
 you would
have a much simpler task: just call Net[32]UserValidate().
The server (and requester?) package contains INF, header, lib and
 samples how
to do this.  Look for x:\IBMLAN\NETSRC (don't remember the
 installation option,
sorry).

C-x C-s
    Vitus




--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                      12-Nov-99 01:46:00
  To: All                                               11-Nov-99 16:48:03
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail]

From: [e-mail] (Kevin)

On 10 Nov 1999 11:00:58 GMT, yourself@127.0.0.1 (Rich Walsh) wrote:

>On Tue, 9 Nov 1999 21:58:56, [e-mail] (Kevin)
 wrote:
>
>> I have a massive PM application with hundreds and hundreds of
 entry
>> fields. It is used on 21 inch montiors and users are complaining
 that
>> they can't see the entry field cursor on the large screens.
>> Subclassing entry fields is not an option in this environment. So
 I
>> thought I could superclass WC_ENTRYFIELD. I have created a DLL
 with an
>> initialisation routine that attempts to get the class info for
>> WC_ENTRYFIELD, store the address of the window proc and register a
>> CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when
 it
>> receives the focus it can call the original WC_ENTRYFIELD wnd proc
 and
>> then create a new cursor that is more visible.
>>
>> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's
 called).
>> The DLL loads and executes its initialisation. WinQueryClassInfo
 gets
>> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
>> CS_PUBLIC gets FALSE. But after re-booting, any window with an
 entry
>> field traps. This tends to indicate that my wndproc is being
 called,
>> even though I got FALSE on the register. I wonder if the address
>> returned by WinQueryClassInfo is valid in all the other processes.
>>
>>I believe from a search on DEJA that Rich Walsh has done this kind
 of
>>thing before. What I want to do is register my own wndproc for all
>>WC_ENTRYFIELD controls created and create a different cursor every
>>time an entry field gets the focus. What am I doing wrong?
>
>Do you really want to modify every entryfield in the system or just
 the
>ones in your app?  Either way, you'll have to deal with odd
 side-effects
>your code may have on, say, read-only comboboxes (i.e. no visible
 cursor).

Users would be happy with every entryfield in the system. This is the
only app being used, so I don't have to worry about other people's
apps. Didn't thing about the comboboxes, but their entryfields are
easy enough to distinguish from ordinary ones.

>For a global replacement, the superclassing code in your DLL should
 only
>be executed once:  the first time it's called, when it's operating
 in the
>shell process.  You shouldn't have to change any flags.  You can
 store
>the original PFN in global memory because it's valid in all PM
 processes.

Thanks for clearing that up.

The WinRegisterClass call returns FALSE when I try to register with
all the parameters from WinGetClassInfo the same except for PFNWP.
Haven't done WinGetLastError here yet as I was trying Peter
Fitzsimmons' idea today. Don't know if I believe the return value
though because I was getting traps on anything that created an
entryfield.

>The traps you're getting now probably occur because the DLL's
 instance
>data hasn't been initialized properly (are you using INITINSTANCE
 and
>DATA MULTIPLE NONSHARED ?).  Since your needs are so minimal, you
 may
>not even need a per-process data segment except to satisfy your
 compiler.
>If so, try shedding the runtime environment - or even the runtime
 itself
>(YMMV).

I had INITINSTANCE and DATA MULTIPLE NONSHARED in all cases.
Currently using the runtime for fprintf for debugging, but will
probably not use it in the end.

>BTW...  are you aware that the function you've exported as ordinal 1
>gets called every time your dll is loaded into a new process?
Hmmm. I am exporting by names, but the first export is my
initialisation function. This function does get called on load as my
fprintf shows.

>For a process-specific solution, forget most everything I just said
 :-)
>AFAIK, you can't reregister a CS_PUBLIC class for a particular
 process.

That is correct according to the documentation.

>Instead, you can try this strategy (one of several that come to
 mind):
>identify whether the message that causes an e/f to create its cursor
>is posted or sent.  Then use either an InputHook or a SendMsgHook on
>your *own* message queue (HMQ_CURRENT) to intercept it.  This will
>let you put the code in your exe, avoid sub- or superclassing, and
>generally limit the damage.  (IMHO, this is a good solution when
>you're messing with your own app, and a lousy solution when you're
>messing other people's.)

Have been playing with hooks today. Wanted to used Peter's suggestion
to use a hook to catch all WM_CREATE messages and subclass
WC_ENTRYFIELDS. Have tried all the 'message' type hooks, but so far
none seem to get WM_CREATE messages. Hoping Peter's code will help
here.

The private hook is interesting. The entryfield has to create/destroy
the cursor on one of the activate/focuschange type messages. I will
look into that more tomorrow.

Thanks,
Kevin



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                              12-Nov-99 01:46:00
  To: All                                               11-Nov-99 16:48:03
Subj: Re: XCPT_SPACE_ACCESS Violation in DOSCALL1

From: [e-mail]

From: Dave Blaschke <[e-mail]>



Mike Fry wrote:

Ahh, Mike Fry, the man who asked me to add yet another executable to
 the
OS2TRACE package.  Because it's you I'll try and answer correctly for
 a
change ;-)

> Could someone help me with this entry from the POPUPLOG.OS2 on a
 Warp 4,
> FP12 machine?
>
> Unfortunately, I didn't write the offending program (it's in 16-bit
> COBOL of all things), but I have written a lot of underlying
 routines
> (Watcom C) that live in DLLs, along with various service programs.
 All C
> code is 32-bit. The DLLs used by the COBOL program have equivalent
> 16-bit and 32-bit entry points (Watcom is good for this sort of
 thunking
> <g>).
>
> 11-05-1999  14:30:29  SYS3171  PID 0029  TID 0001  Slot 0053
> C:\DLRC\MCHOTB04.EXE
> c0000005
> 1bfa0184
> P1=00000008  P2=00000134  P3=XXXXXXXX  P4=XXXXXXXX
> EAX=00000079  EBX=000047fc  ECX=0000001f  EDX=0000eb84
> ESI=00002590  EDI=00002800
> DS=a447  DSACC=00f3  DSLIM=000047ff
> ES=a44f  ESACC=00f3  ESLIM=00001aef
> FS=150b  FSACC=00f3  FSLIM=00000030
> GS=0000  GSACC=****  GSLIM=********
> CS:EIP=dfd7:00000184  CSACC=00df  CSLIM=0000dc08
> SS:ESP=0137:000009f2  SSACC=****  SSLIM=********
> EBP=000009f2  FLG=00012202
>
> DOSCALL1.DLL 0003:00000184
>
> I don't really understand the SYS3171 - exception within exception.
 As
> far as I know, my DLLs don't use exception handlers apart from what
 the
> CRT installs. Is it possible to determine which routine in
 DOSCALL1.DLL
> this trap actually occurred in?

SYS3171 simply means that a thread did not have enough stack space
 available
to dispatch an exception.  When an exception occurs, the OS/2 kernel
attempts to "push" an exception report record and context record,
 along with
some other goodies,  on top of the user's stack for the ring 3
 exception
dispatcher: if this fails, a SYS3171 will result.  This does not
 necessarily
mean that an exception occurred within a handler.

As for the routine, you can't really figure it out without the
 DOSCALL1.MAP
file or some debug tools that can extract the info from DOSCALL1.SYM.
  In
this case, DOSCALL1 object 3 offset 184 is within the DOSSEMWAIT API
 on
FP12.

>
>
> My suspicion is that this is some kind of application-caused memory
> leak. Examination of the C & COBOL source code shows that tiled
 memory
> objects are being allocated by DosAllocSharedMem in one of my
 service
> EXEs and passed to the COBOL program, via a queue, after doing a
> DosGiveSharedMem to give the COBOL program read/write permission.
 The
> service EXE then does a DosFreeMem.
>
> At some stage on the COBOL side, an apparently unnecessary
 DosGetSeg
> (16-bit remember) is being done. I say unnecessary because the
 program
> already has read/write access to the object thru the
 DosGiveSharedMem
> call. I can only find a single DosFreeSeg in the COBOL code. Am I
 right
> in thinking that OS/2 is unable to 'physically' free the memory
 objects
> because of a non-zero reference count? And that over time, OS/2
 will
> actually 'run out' of memory?
>
> To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION.
> According to my toolkit headers, the P1 value indicates
> XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has
 actually run
> out of selectors because of the unnecessary DosGetSeg (missing
> DosFreeSeg), then I would have expected to find P1 to indicate
> XCPT_LIMIT_ACCESS.
>
> I can't find any explanation in my documentation of what these two
> access violation codes mean in real terms. Can anybody explain the
> difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my
> description of the memory object usage make sense in terms of the
 trap
> information that I have supplied?

Both indicate that a trap C occurred.  If P1 == XCPT_SPACE_ACCESS,
 then the
trap C  occurred with a non-zero error code and P2 = this error code.
  If P1
== XCPT_LIMIT_ACCESS, then the trap C occurred with a zero error code
 and P2
= XCPT_DATA_UNKNOWN.  The following is from the Intel programmer's
reference, where stack fault refers to trap C:

<CITE>
A stack fault is generated under two conditions:

* As a result of a limit violation in any operation which refers to
 the SS
register.  This includes stack-oriented instructions such as POP,
 PUSH,
ENTER, and LEAVE, as well as other memory
references which implicitly use the stack (for example, MOV
 AX,[BP+6]).  The
ENTER instruction generates this exception when there is too little
 space
for allocating local variables.

* When attempting to load the SS register with a descriptor which is
 marked
segment-not-present but is otherwise valid.  This can occur in a task
switch, a CALL instruction ro a different privilege level, a return
 to a
different privilege level, an LSS instruction, or a MOV or POP
 instruction
to the SS register.

When the processor detects a stack exception, it pushes an error code
 onto
the stack of the exception handler.  If the exception is due to a
not-present stack segment or to overflow of the new stack during an
interlevel CALL, the error code contains a selector to the segment
 which
caused the exception (the exception handler can test the present bit
 in the
descriptor to determine which exception occurred); otherwise, the
 error code
is 0.
</CITE>

>
>
> Thanks for listening,
> MIKE FRY
> mailto:[e-mail]





--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                 12-Nov-99 01:46:01
  To: All                                               11-Nov-99 16:48:03
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail]

From: [e-mail]

From: yourself@127.0.0.1 (Rich Walsh)

On Tue, 9 Nov 1999 21:58:56, [e-mail] (Kevin)
 wrote:

> I have a massive PM application with hundreds and hundreds of entry
> fields. It is used on 21 inch montiors and users are complaining
 that
> they can't see the entry field cursor on the large screens.
> Subclassing entry fields is not an option in this environment. So I
> thought I could superclass WC_ENTRYFIELD. I have created a DLL with
 an
> initialisation routine that attempts to get the class info for
> WC_ENTRYFIELD, store the address of the window proc and register a
> CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when
 it
> receives the focus it can call the original WC_ENTRYFIELD wnd proc
 and
> then create a new cursor that is more visible.
>
> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's
 called).
> The DLL loads and executes its initialisation. WinQueryClassInfo
 gets
> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
> CS_PUBLIC gets FALSE. But after re-booting, any window with an
 entry
> field traps. This tends to indicate that my wndproc is being
 called,
> even though I got FALSE on the register. I wonder if the address
> returned by WinQueryClassInfo is valid in all the other processes.
>
>I believe from a search on DEJA that Rich Walsh has done this kind
 of
>thing before. What I want to do is register my own wndproc for all
>WC_ENTRYFIELD controls created and create a different cursor every
>time an entry field gets the focus. What am I doing wrong?

Do you really want to modify every entryfield in the system or just
 the
ones in your app?  Either way, you'll have to deal with odd
 side-effects
your code may have on, say, read-only comboboxes (i.e. no visible
 cursor).

For a global replacement, the superclassing code in your DLL should
 only
be executed once:  the first time it's called, when it's operating in
 the
shell process.  You shouldn't have to change any flags.  You can
 store
the original PFN in global memory because it's valid in all PM
 processes.

The traps you're getting now probably occur because the DLL's
 instance
data hasn't been initialized properly (are you using INITINSTANCE and
DATA MULTIPLE NONSHARED ?).  Since your needs are so minimal, you may
not even need a per-process data segment except to satisfy your
 compiler.
If so, try shedding the runtime environment - or even the runtime
 itself
(YMMV).

BTW...  are you aware that the function you've exported as ordinal 1
gets called every time your dll is loaded into a new process?

For a process-specific solution, forget most everything I just said
 :-)
AFAIK, you can't reregister a CS_PUBLIC class for a particular
 process.

Instead, you can try this strategy (one of several that come to
 mind):
identify whether the message that causes an e/f to create its cursor
is posted or sent.  Then use either an InputHook or a SendMsgHook on
your *own* message queue (HMQ_CURRENT) to intercept it.  This will
let you put the code in your exe, avoid sub- or superclassing, and
generally limit the damage.  (IMHO, this is a good solution when
you're messing with your own app, and a lousy solution when you're
messing other people's.)


   == == almost usable email address:  rlwalshATpacket.net == ==
___________________________________________________________________

                |             - DragText v3.1 -
Rich Walsh      |  A Distinctly Different Desktop Enhancement
Ft Myers, FL    |  New!  Pickup & Drop for text, and more...
                |  http://www.usacomputers.net/personal/rlwalsh/
___________________________________________________________________





--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                   12-Nov-99 01:46:01
  To: All                                               11-Nov-99 16:48:03
Subj: XCPT_SPACE_ACCESS Violation in DOSCALL1

From: [e-mail]

From: [e-mail]

From: [e-mail] (Mike Fry)

Could someone help me with this entry from the POPUPLOG.OS2 on a Warp
 4,
FP12 machine?

Unfortunately, I didn't write the offending program (it's in 16-bit
COBOL of all things), but I have written a lot of underlying routines

(Watcom C) that live in DLLs, along with various service programs.
 All C
code is 32-bit. The DLLs used by the COBOL program have equivalent
16-bit and 32-bit entry points (Watcom is good for this sort of
 thunking
<g>).

11-05-1999  14:30:29  SYS3171  PID 0029  TID 0001  Slot 0053
C:\DLRC\MCHOTB04.EXE
c0000005
1bfa0184
P1=00000008  P2=00000134  P3=XXXXXXXX  P4=XXXXXXXX
EAX=00000079  EBX=000047fc  ECX=0000001f  EDX=0000eb84
ESI=00002590  EDI=00002800
DS=a447  DSACC=00f3  DSLIM=000047ff
ES=a44f  ESACC=00f3  ESLIM=00001aef
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=dfd7:00000184  CSACC=00df  CSLIM=0000dc08
SS:ESP=0137:000009f2  SSACC=****  SSLIM=********
EBP=000009f2  FLG=00012202

DOSCALL1.DLL 0003:00000184

I don't really understand the SYS3171 - exception within exception.
 As
far as I know, my DLLs don't use exception handlers apart from what
 the
CRT installs. Is it possible to determine which routine in
 DOSCALL1.DLL
this trap actually occurred in?

My suspicion is that this is some kind of application-caused memory
leak. Examination of the C & COBOL source code shows that tiled
 memory
objects are being allocated by DosAllocSharedMem in one of my service

EXEs and passed to the COBOL program, via a queue, after doing a
DosGiveSharedMem to give the COBOL program read/write permission. The

service EXE then does a DosFreeMem.

At some stage on the COBOL side, an apparently unnecessary DosGetSeg
(16-bit remember) is being done. I say unnecessary because the
 program
already has read/write access to the object thru the DosGiveSharedMem

call. I can only find a single DosFreeSeg in the COBOL code. Am I
 right
in thinking that OS/2 is unable to 'physically' free the memory
 objects
because of a non-zero reference count? And that over time, OS/2 will
actually 'run out' of memory?

To me, this is a fairly straight-forward XCPT_ACCESS_VIOLATION.
According to my toolkit headers, the P1 value indicates
XCPT_SPACE_ACCESS and P2 the selector involved. If OS/2 has actually
 run
out of selectors because of the unnecessary DosGetSeg (missing
DosFreeSeg), then I would have expected to find P1 to indicate
XCPT_LIMIT_ACCESS.

I can't find any explanation in my documentation of what these two
access violation codes mean in real terms. Can anybody explain the
difference between XCPT_SPACE_ACCESS and XCPT_LIMIT_ACCESS? Does my
description of the memory object usage make sense in terms of the
 trap
information that I have supplied?

Thanks for listening,
MIKE FRY
mailto:[e-mail]





--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                 12-Nov-99 01:46:02
  To: All                                               11-Nov-99 16:48:03
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail]

From: yourself@127.0.0.1 (Rich Walsh)

On Wed, 10 Nov 1999 21:28:40, [e-mail] (Kevin)
 wrote:
> On 10 Nov 1999 11:00:58 GMT, yourself@127.0.0.1 (Rich Walsh) wrote:
> >On Tue, 9 Nov 1999 21:58:56, [e-mail] (Kevin)
 wrote:
> >
> >> I have a massive PM application with hundreds and hundreds of
 entry
> >> fields. It is used on 21 inch montiors and users are complaining
 that
> >> they can't see the entry field cursor on the large screens.
> >> Subclassing entry fields is not an option in this environment.
 So I
> >> thought I could superclass WC_ENTRYFIELD.
[big snip]
> >Instead, you can try this strategy (one of several that come to
 mind):
> >identify whether the message that causes an e/f to create its
 cursor
> >is posted or sent.  Then use either an InputHook or a SendMsgHook
 on
> >your *own* message queue (HMQ_CURRENT) to intercept it.  This will
> >let you put the code in your exe, avoid sub- or superclassing, and
> >generally limit the damage.  (IMHO, this is a good solution when
> >you're messing with your own app, and a lousy solution when you're
> >messing other people's.)
>
> Have been playing with hooks today. Wanted to used Peter's
 suggestion
> to use a hook to catch all WM_CREATE messages and subclass
> WC_ENTRYFIELDS. Have tried all the 'message' type hooks, but so far
> none seem to get WM_CREATE messages. Hoping Peter's code will help
> here.
>
> The private hook is interesting. The entryfield has to
 create/destroy
> the cursor on one of the activate/focuschange type messages. I will
> look into that more tomorrow.

DragText v1.x used the method Peter described (minus the SYS_DLLS
entry).  It had a flaw that you may consider a feature.  Comboboxes
and spinbuttons create entryfields which your code subclasses and
their code then re-subclasses.  They don't bother saving your PFNWP
and have their subprocs call the class's base window procedure
 instead
of yours.  Unless you subclass these controls too (as DT did), your
code will never be called when the entryfield is part of another
control.

You can do this entirely within your own app by installing a
 HK_SENDMSG
for each thread that creates entryfields (probably only the first).
This should eliminate access violations and let you retain your
C runtime.  Like IBM, you'll have to decide whether to discard each
window's PFNWP and use the class's default.

FWIW...  After I posted my earlier suggestion, I realized it won't
work if you have to use a HK_SENDMSG.  You want to create a cursor
after an e/f has handled a particular message but this hook gives
you no way to do so and no way to keep the message from being passed
on (with a HK_INPUT, your hook could dispatch the message itself,
do its thing on return, then terminate further processing).
Sorry 'bout that...


   == == almost usable email address:  rlwalshATpacket.net == ==
___________________________________________________________________

                |             - DragText v3.1 -
Rich Walsh      |  A Distinctly Different Desktop Enhancement
Ft Myers, FL    |  New!  Pickup & Drop for text, and more...
                |  http://www.usacomputers.net/personal/rlwalsh/
___________________________________________________________________



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                   12-Nov-99 01:46:01
  To: All                                               11-Nov-99 16:48:03
Subj: USE or SPY any distant PC via LAN/INTERNET

From: [e-mail]

From: [e-mail]

From: "Crowsort" <[e-mail]>

USE or SPY any distant PC via LAN/INTERNET

How YOU can Hack Windows 95-98-NT... in seconds!
And use or spy any PC via a LAN or the Internet... as if you were
 there!

Platforms concerned:
--------------------
=> Windows 95/98
=> Windows NT Workstation/Server 3.5, 3.51 and 4.0
=> Windows 2000

Whether you are a rookie or a seasoned hacker, there are times where
you want to do something RAPIDLY.

Some of us worked a lot to enhance password cracking but we have to
recognize that if passwords have been carefully chosen, it still
 takes a
lot of TIME.

Others are using well-known security holes in NT but we also have to
recognize that the ways to use those security breaches are not easy
and it also takes TIME to understand and to implement them.

There is a way to get all the passwords of *any* version of Windows
INSTANTLY. There is a way to control a distant machine 'as if you
 were
there'.

Netbus and BO2K were good attempts, I used them for months, but
 despite of
what their authors said, using it every day is difficult and
 frustrating
enough to
disgust lazy guys like me... the fact that I cannot see the distant
 screen
in
real-time is really frustrating!

A friend demonstrated me RA.

RA (Remote-Anything) is THE solution you were looking for: it shows
 in
real-time the distant desktop (like PC-Anywhere and other MB-based
commercial products) BUT the server (the program you install on the
 PC
you want to control) is **80 KB** long...

You can install it remotely by using the buffer overflows of Outlook
 Express
or IE4 or simply by sending it as an Email attachment!

Better than that: once installed, it does not show in the Task-List,
 can't
be discovered or killed with CTRL-ALT-DEL!

Once you poisoned PCs on a LAN, no need to remember which ones: RA
is able to find automatically available PCs and displays IP addresses
 and
DNS Names! Just click on one of them to be connected!

And it is so fast that you can see any animation playing on the
 distant PC
in real-time!

All this from one unique tool... Damned, I got it!
____________________________________________________

Here are some of the functions I picked-up from RA's Doc:

o Connect to a new desktop: opens the Connection Dialog Box which
 allows you
to open a
  new window on a new Desktop (you can watch multiple Desktops at a
 time).

o Monitor only: will toggle the passive-monitoring and active-control
 modes
(active
  monitoring allows you to type keys and move the mouse on the
 distant PC
while passive
  monitoring will only allow you to watch only).

o Full screen: will enter the full-screen mode. You can exit it by
 typing
CTRL+ESC and
  then right-clicking the Master's task bar icon to come back to the
windowed mode.

o Remove wallpaper on distant desktop: is useful to minimize the
 amount of
data sent
  over the network. It always speedups a connection.

o Start Screen Saver: is useful when you want to leave the desktop
 with a
screensaver
  running: when Remote-Anything moves the mouse cursor on a Slave
 desktop,
it stops
  the screensaver if it was running. With this option, you can
 immediately
run the
  screensaver (use this option with the keyboard shortcut to avoid
 moving
the mouse
  in active mode or switch to passive monitoring to activate this
 menu
option with
  the mouse). If the screensaver is password protected, this is a way
 to
lock the
  distant PC.

o Play a Sound: will make a sound being played on the distant PC.
 Usually it
is
  'ding.wav' but it can be any sound the distant PC registered as the
default sound.

o Send commands: will display a Dialog Box equivalent to the
 Start/Run
command of
  Windows 95.

o Get Passwords of distant PC: get all the network passwords, the
screensaver password,
  and the Applications passwords Windows has been asked to remember.

o Lockup distant PC: Hangs the distant PC which will need to be
 restarted
manually.

o Reboot distant PC: will immediately send the order to reboot to the
distant PC, this
  will disconnect you from this Desktop but you can reconnect once
 the
distant Windows
  session is active again.

o Shut Down distant PC: will shut down the distant PC if it supports
 shut
down. You
  will be disconnected.
_____________________________________________________

o How does it work?
  -----------------
It is as simple as using Windows 98 itself: move the mouse, type
 keys, the
distant PC will do everything you want! It works over LANs and the
 Internet!

o Where can I get it?
  -------------------
At the moment, you can get it from:

http://www.twd-industries.com

You'll have to pay a small fee to the authors to get RA. I can tell
 you that
it's worth the price: I simply did things I would never have been
 able to
do without it.
If you have access to a local network, RA will allow you to do
 whatever
you want! This tool is so easy to use that every hacker will want it.

The more you wait, the less what you can do with it will remain a
 secret!
But as time goes, I guess it will be available from a lot of other
 places.

Have fun!

   ººººººº
  ºº ººº ºº
º   ~   ~   º
@<ñ>"<ñ>@
  (       ~      )
    \  'v=v'   /    The Crowsort is back.
     |\____/|
_____________________________________________________










--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                 12-Nov-99 01:46:02
  To: All                                               11-Nov-99 16:48:03
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail]

From: [e-mail] (Bob Plyler)
Reply-To: [e-mail] (Bob Plyler)

In <[e-mail]>, [e-mail]
 (Kevin) writes:
>I have a massive PM application with hundreds and hundreds of entry
>fields. It is used on 21 inch montiors and users are complaining
 that
>they can't see the entry field cursor on the large screens.
>Subclassing entry fields is not an option in this environment. So I
>thought I could superclass WC_ENTRYFIELD. I have created a DLL with
 an
>initialisation routine that attempts to get the class info for
>WC_ENTRYFIELD, store the address of the window proc and register a
>CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when
 it
>receives the focus it can call the original WC_ENTRYFIELD wnd proc
 and
>then create a new cursor that is more visible.

Simple question.  Why not just replace the Cursors?
You can replace them with system supplied cursors in
the Mouse settings.  You can modify these cursors via ICONEDIT

Bob Plyler

IBM 3890/XP Engineering  (not an official IBM spokesperson)



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                12-Nov-99 01:46:01
  To: All                                               11-Nov-99 16:48:03
Subj: Re: VAC++ debugger storage monitor: how to search for specific data?

From: [e-mail]

From: [e-mail] (Arie Kazachin)
Reply-To: [e-mail]

In message <[e-mail]> - Tue, 09 Nov 1999 12:42:01
-0500Jerry Stuckle <[e-mail]> writes:
>
>Arie,
>
>Sorry, you can't search for specific data - I assume part of the
 reason
>could be that memory is not necessarily contiguous in OS/2, even
 with
>virtual addresses.
>
>A trick I've used quite often is to set a pointer to the data I want
 to
>monitor, then stop when the pointer is set.  This will give me the
>address of the data, and I can then set a breakpoint on the change.
>

Thanks, Jerry.

However, this trick only works when debugging a program you write.
When attempting to do this with already existing executable (and no
 sources),
it seems I'll have to let go on tha ability to search for data
 (unless
some developing/debugging utilities can do this).

Regards,
**********************************************************************
*******
*   Arie Kazachin, Israel, e-mail:
 [e-mail] *
**********************************************************************
*******
NOTE: before replying, leave only letters in my domain-name. Sorry,
 SPAM trap.



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                12-Nov-99 01:46:01
  To: All                                               11-Nov-99 16:48:03
Subj: sys/param.h and in.h on other systems

From: [e-mail]

From: Joe Heafner <[e-mail]>

Hi.

I have some software that was designed to work under EMX, DJGPP, and
other systems equipped with gcc. It also compiles under VC++ on Win
systems. The programs make use of the sys/param.h and in.h header
 files.
When I attempt to compile the code under MingW32 (the Win32 port of
 gcc
2.9) the compiler complains about not being able to find these header
files.

Can anyone tell me the header files I should use under MingW23 to
compile these programs?

Someone else also told me that these particular header files are not
part of the ANSI/ISO C standard. All I know is that ever
 compiler/system
I've tested my software on apparently has these files and experiences
 no
problems. The only compiler to have a problem so far is MingW32. If
these files are not ANSI compliant, what are the appropriate ANSI
 header
files to use? The software, I belive (I didn't write this particular
part), uses these header files for functions needed to check and, if
necessary, change byte ordering (big endian vs. little endian) in
certain situations.


            Thanks,
--

                        -- Joe Heafner

Joe Heafner, Astronomy and Physics Instructor. Work:[phone]
 x4246
my surname with my first initial at interpath dot com
http://home.interpath.com/heafnerj/


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                  12-Nov-99 01:46:02
  To: All                                               11-Nov-99 16:48:03
Subj: Re: sys/param.h and in.h on other systems

From: [e-mail]

From: [e-mail] (Bob Eager)

On Thu, 11 Nov 1999 00:03:10, Joe Heafner <[e-mail]>
wrote:

> I have some software that was designed to work under EMX, DJGPP,
 and
> other systems equipped with gcc. It also compiles under VC++ on Win
> systems. The programs make use of the sys/param.h and in.h header
 files.
> When I attempt to compile the code under MingW32 (the Win32 port of
 gcc
> 2.9) the compiler complains about not being able to find these
 header
> files.

Where did you get the header files for the other compilers? If in a
toolkit, then if MingW32 can't find them you probably have it looking

in the wrong place.

> Can anyone tell me the header files I should use under MingW23 to
> compile these programs?

The same ones you used for the others.

> Someone else also told me that these particular header files are
 not
> part of the ANSI/ISO C standard. All I know is that ever
 compiler/system
> I've tested my software on apparently has these files and
 experiences no
> problems.

That's right. These headers are non-ANSI. The sys\param.h is
essentially a kernel configuration file on UNIX systems. The
occasional constant in there escapes for use by programs. The in.h
 (in
netinet\in.h on my system) contains networking stuff.

> The only compiler to have a problem so far is MingW32.

Sounds like the setup.

> If
> these files are not ANSI compliant, what are the appropriate ANSI
 header
> files to use?

There aren't.

> The software, I belive (I didn't write this particular
> part), uses these header files for functions needed to check and,
 if
> necessary, change byte ordering (big endian vs. little endian) in
> certain situations.

I can believe that the files you mention contain these functions. But

they aren't part of ANSI. Saying that you've seen them on every
 system
so far doesn' MAKE then suddnly ANSI.

I repeat, I think the set of headers you're using with the compiler
 is
incomplete. Or its INCLUDE environment variable isn't picking up the
toolkit directory.
--
Bob Eager
rde at tavi.co.uk
PC Server 325; PS/2s 8595*3, 9595*3 (2*P60 + P90), 8535, 8570,
 9556*2,
8580*6,
8557*2, 8550, 9577, 8530, P70, PC/AT..


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                       12-Nov-99 01:46:03
  To: All                                               11-Nov-99 16:48:03
Subj: Problems when handling WM_PAINT in a second thread

From: [e-mail]

From: [e-mail]

In a graphics application I am passing all WM_PAINT messages on to a
worker thread ("object window") for doing the real painting because
 it
takes some time to complete and I do not want to block the program
entirely. The user can issue e.g. a "zoom in" command while the
 graphics
is still being drawn and the response is immediate: Stop the first
repaint and start a new one with everything enlarged, etc. Works so
 far
very nicely.

However, a problem arises when I want to resize the window: It
 happens
frequently that the size just "jumps" to something completely wrong,
e.g. width zero or so. It only happens if the "move whole windows"
option is turned on, i.e. resizing means a whole avalanche of
 WM_PAINT
messages are arriving and competing with each other. I found a way to
handle this, with partial success, trying to set a flag "don't
 repaint"
while a resize action is on the way. In most cases this prevents the
strange "jumping resize", but still not always. OTOH sometimes the
 final
repaint doesn't seem to work and has to be forced somehow manually.

There is a certain chance that the problem even has something to do
 with
the multiple desktop feature of OD which I am running (v1.52
"professional").

QUESTION:

Does anybody see an entirely different setup for achieving the
responsiveness I want while long repaints are going on without
 running
into the problems I got?

Greetings and thanks for any hints,

Cornelis Bockemⁿhl

e-mail: [e-mail]
author of "PmAs - Astronomy for the Presentation Manager"
at http://www.datacomm.ch/cobo


Sent via Deja.com http://www.deja.com/
Before you buy.


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                  12-Nov-99 01:46:03
  To: All                                               11-Nov-99 16:48:03
Subj: Re: Problems when handling WM_PAINT in a second thread

From: [e-mail]

From: Jerry Stuckle <[e-mail]>
Reply-To: [e-mail]

I've done a lot with painting like this - especially things which
 take a
long time like changing the sizes of bitmaps.

I've found the easiest way to do it is to do your painting to a
 memory
PS.  Then when you get the WM_PAINT messages, just BitBlt the memPS
 to
the window PS.

[e-mail] wrote:
>
> In a graphics application I am passing all WM_PAINT messages on to
 a
> worker thread ("object window") for doing the real painting because
 it
> takes some time to complete and I do not want to block the program
> entirely. The user can issue e.g. a "zoom in" command while the
 graphics
> is still being drawn and the response is immediate: Stop the first
> repaint and start a new one with everything enlarged, etc. Works so
 far
> very nicely.
>
> However, a problem arises when I want to resize the window: It
 happens
> frequently that the size just "jumps" to something completely
 wrong,
> e.g. width zero or so. It only happens if the "move whole windows"
> option is turned on, i.e. resizing means a whole avalanche of
 WM_PAINT
> messages are arriving and competing with each other. I found a way
 to
> handle this, with partial success, trying to set a flag "don't
 repaint"
> while a resize action is on the way. In most cases this prevents
 the
> strange "jumping resize", but still not always. OTOH sometimes the
 final
> repaint doesn't seem to work and has to be forced somehow manually.
>
> There is a certain chance that the problem even has something to do
 with
> the multiple desktop feature of OD which I am running (v1.52
> "professional").
>
> QUESTION:
>
> Does anybody see an entirely different setup for achieving the
> responsiveness I want while long repaints are going on without
 running
> into the problems I got?
>
> Greetings and thanks for any hints,
>
> Cornelis Bockemⁿhl
>
> e-mail: [e-mail]
> author of "PmAs - Astronomy for the Presentation Manager"
> at http://www.datacomm.ch/cobo
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--

=======================================================
To reply, delete the "x" from my email address

Jerry Stuckle
[e-mail]
JDS Computer Training Corp.
Sun Certified Java Programmer
VisualAge/Java Certified Advanced Technical Expert
VisualAge/C++ Certified Developer

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


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Skynet Titan (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                          11-Nov-99 14:45:04
  To: All                                               11-Nov-99 16:48:03
Subj: SOMobjects Toolkit Availability?

From: "andrew g" <[e-mail]>

If you know where on IBM I can find the SOMobjects toolkit, please let me
know.

Thanks,

andrew


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Introits and Graduals Co. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                      11-Nov-99 21:32:23
  To: All                                               11-Nov-99 19:59:17
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail] (Kevin)

On 11 Nov 1999 12:52:33 GMT, [e-mail] (Bob Plyler)
wrote:

>In <[e-mail]>, [e-mail] (Kevin)
writes:
>>I have a massive PM application with hundreds and hundreds of entry
>>fields. It is used on 21 inch montiors and users are complaining that
>>they can't see the entry field cursor on the large screens.
>>Subclassing entry fields is not an option in this environment. So I
>>thought I could superclass WC_ENTRYFIELD. I have created a DLL with an
>>initialisation routine that attempts to get the class info for
>>WC_ENTRYFIELD, store the address of the window proc and register a
>>CS_PUBLIC control called WC_ENTRYFIELD. The intention is that when it
>>receives the focus it can call the original WC_ENTRYFIELD wnd proc and
>>then create a new cursor that is more visible.
>
>Simple question.  Why not just replace the Cursors?
>You can replace them with system supplied cursors in
>the Mouse settings.  You can modify these cursors via ICONEDIT

You're thinking of pointers. I want to replace the cursors - those
blinking lines you see in entry fields. These are drawn dynamically by
the system - there is no bitmap for them.

>
>Bob Plyler
>
>IBM 3890/XP Engineering  (not an official IBM spokesperson)

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Organization (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                      11-Nov-99 21:32:24
  To: All                                               11-Nov-99 19:59:17
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail] (Kevin)

Peter,

Thanks so much for your code. I took the advice from you and Rich and
used the SENDMSG hook. I intercept WM_CONTROL messages for
EN_SETFOCUS/MLN_SETFOCUS and create my cursor. Had to add code for
WM_BUTTON1UP, but it works like a charm.

Your code helped me find my fatal error - the hook procedure has to be
EXPENTRY, not APIENTRY. I hate when that happens! So that made a mess
of the stack.

Just have some fine tuning for MLEs (imagine that) and a setup utility
and its done. Now that I don't need the fprintfs any more, I can also
drop the C runtime. Could you possibly post me an OBJ for your ASM
entry point code? I don't have access to MASM and without it I have to
use the C runtime and its _DLL_InitTerm function to do my own
initialisation procedure.

Would post the code somewhere, if I only knew where or thought that
any but the hard core were still doing OS/2!

thanks again,
Kevin


On Fri, 12 Nov 1999 01:46:01 GMT, [e-mail] wrote:

>From: [e-mail]
>
>From: Peter Fitzsimons <[e-mail]>
>
>> I list my DLL in SYS_DLLS->LoadEachProcess (or whatever it's
> called).
>> The DLL loads and executes its initialisation. WinQueryClassInfo
> gets
>> TRUE for WC_ENTRYFIELD. WinRegisterClass for WC_ENTRYFIELD with
>> CS_PUBLIC gets FALSE. But after re-booting, any window with an
> entry
>> field traps. This tends to indicate that my wndproc is being
> called,
>
>How are you defining your data segments?  ie:"single shared", or
> what?
>
>If you are loading anything (like a pointer/icon/bmp) you have to do
> it
>for each app, which probably forces you do use an "initinstance
> multiple
>nonshared" dll. So keep your data segment size down, and try to
> compile
>/Rn.
>
>I have code that subclasses the titlebar for every app with a sys_dll
>"load once" entry.  It installs a msg hook, that looks for WM_CREATE
>messages;  if the window is what I'm looking for, then I subclass it
>"live". I'm a resource freak and the thought of "loadperprocess" and
>"mutliple data" offended me at the time (1995, when I only had 24mb
> of
>memory I think :).
>
>Anyway, you're welcome to the code if you like.
>
>
>

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Organization (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                           11-Nov-99 15:39:17
  To: All                                               11-Nov-99 19:59:17
Subj: Re: Problems when handling WM_PAINT in a second thread

From: Jerry Stuckle <[e-mail]>

Cornelis,

>
> Or maybe with a modification: The "object window" draws into a memory PS
> and from time to time sends a message to the main thread telling it to
> copy the current image to the screen... (??!)
>

Yes - after drawing into the object window, the object thread
invalidates the main window, causing a WM_PAINT message to be posted and
the main window redrawn.


--

=======================================================
To reply, delete the "x" from my email address

Jerry Stuckle
[e-mail]
JDS Computer Training Corp.
Sun Certified Java Programmer
VisualAge/Java Certified Advanced Technical Expert
VisualAge/C++ Certified Developer

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

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: JDS Computer Training Corp. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                      11-Nov-99 21:51:15
  To: All                                               11-Nov-99 19:59:17
Subj: Re: SYS_DLLS and superclassing native controls

From: [e-mail] ([e-mail])

Kevin? ([e-mail]?) wrote (Thu, 11 Nov 1999 21:32:47 GMT):
>You're thinking of pointers. I want to replace the cursors - those
>blinking lines you see in entry fields. These are drawn dynamically by

You're thinking of the caret.  The mouse cursor is a cursor.  The text
cursor is a caret.

 '`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'`'
 Corne1 Huth  -  http://40th.com/
 Bullet database engines/servers 3.1  Win32-WinCE-OS2-Linux+

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Yanaguana (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                               11-Nov-99 22:18:21
  To: All                                               11-Nov-99 19:59:17
Subj: Re: Detecting MMX processor

From: =?iso-8859-1?Q?Bj=F8rn?= Vermo <[e-mail]>

Mads Orbesen Troest wrote:

>
> .. or simply make sure it is a >= Pentium processor before using the
> cpuid method. MMX extensions do not exist for processors below
> Pentium.
>

The old IIT 80c287 had something very like it. I have one in my old OS/2 1.3
computer.


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Norbionics (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                                11-Nov-99 15:30:04
  To: All                                               11-Nov-99 21:27:04
Subj: redirect stdio from program for rexx processing

From: bruno schwander <[e-mail]>

Hi all,
I need to write a rexx script that will start an executable program and
communicate with this program through its standard input/output. How do
I do this ? I know how to redirect the program's output to a file, but
I'd like to redirect it to (for example) a rexx queue, so that the rexx
script can just pull the output from that queue. And the same for the
input of the program.

Any idea how to do this ?

bruno

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Posted via Supernews, http://www.supernews.com (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                           11-Nov-99 18:17:08
  To: All                                               12-Nov-99 03:36:02
Subj: Re: sys/param.h and in.h on other systems

From: [e-mail]

In article <176uZD2KcidF-pn2-mfXb5X5VVrhc@rikki>,
  [e-mail] (Bob Eager) wrote:
> On Thu, 11 Nov 1999 00:03:10, Joe Heafner <[e-mail]>
> wrote:
>
> > I have some software that was designed to work under EMX, DJGPP, and
> > other systems equipped with gcc. It also compiles under VC++ on Win
> > systems. The programs make use of the sys/param.h and in.h header
files.
> > When I attempt to compile the code under MingW32 (the Win32 port of
gcc
> > 2.9) the compiler complains about not being able to find these
header
> > files.
>
> Where did you get the header files for the other compilers? If in a
> toolkit, then if MingW32 can't find them you probably have it looking
> in the wrong place.
>
These header files are part of the standard distributions. I'm not using
any toolkits (don't even have any).

> > Can anyone tell me the header files I should use under MingW23 to
> > compile these programs?
>
> The same ones you used for the others.
>
Aha....but they don't exist.

> > The only compiler to have a problem so far is MingW32.
>
> Sounds like the setup.
>
I followed the setup docs to the letter. Basically, all I had to do was
unzip the package into its home directory.

> > The software, I belive (I didn't write this particular
> > part), uses these header files for functions needed to check and, if
> > necessary, change byte ordering (big endian vs. little endian) in
> > certain situations.
>
> I can believe that the files you mention contain these functions. But
> they aren't part of ANSI. Saying that you've seen them on every system
> so far doesn' MAKE then suddnly ANSI.
>
Sure, I know that. But it is kinda weird that only one compiler doesn't
seem to have then.

> I repeat, I think the set of headers you're using with the compiler is
> incomplete. Or its INCLUDE environment variable isn't picking up the
> toolkit directory.
>
This is a possibility. I'll check into it.

Thanks!

--
Joe Heafner -- Astronomer
http://home.interpath.com/heafnerj/


Sent via Deja.com http://www.deja.com/
Before you buy.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Deja.com - Before you buy. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                          12-Nov-99 14:49:22
  To: All                                               12-Nov-99 21:25:09
Subj: Real Modem

From: Don McLeod <[e-mail]>

I have a 3Com/USR Internet Voice/Fax modem. I can't get the thing to run
under OS/2 Warp 4. It's NOT a WINMODEM. I can get it to run fine under
DOS, or Linux, but not Warp 4. Does anyone have any suggestions? I've
tried copying the initialize strings and using different modems types
but nothing seems to work.

Thank-you,
Zach McLeod
[e-mail]


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: EarthLink Network, Inc. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                          12-Nov-99 18:37:01
  To: All                                               12-Nov-99 21:25:09
Subj: Re: SOMobjects Toolkit Availability?

From: "andrew g" <[e-mail]>

On 12 Nov 1999 17:51:06 +0100, Martin Schafföner wrote:

>You can't anymore.  The 2.1 version is included with os/2 toolkits,
>and the 3.0 version, which is corba 2.0 compliant and which never
>officially got released, is no more available for download.

I found the version 3 SOMobjects Toolkit at
http://www-4.ibm.com/software/ad/som/som30tk.html
but it's version 2 I want, as my compiler is CSET++ 2.01.

I can't find this version on IBM at all. <sadness>

andrew


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Introits and Graduals Co. (1:109/42)

+----------------------------------------------------------------------------+

From: [e-mail]                        12-Nov-99 23:26:15
  To: All                                               12-Nov-99 21:25:09
Subj: Re: Problem installing a modem on an OS/2 workstation

From: [e-mail] (John Poltorak)

In <[e-mail]>, [e-mail]
(SRuli87202) writes:
>Can somebody help me out here?
>
>I am trying to install a modem on an IBM 730 MT:6877-KAE PC that is running
>OS/2 WARP 4.  I have already installed of the TCPIP/ Internet software and
the
>modem card.
>
>When I click on the Dial button on the OS/2 Internet dialer, I get this error
>message:
>    PPP Driver Failure.
>    Connection ERROR
>
>I have already verified that the COM port and IRQ settings are correctly set
up
>on the jumper settings on the card and that the right COM port was selected
on
>the dialer.  The COM.SYS driver  in the CONFIG.SYS file is set to
>DEVICE=D:\OS2\BOOT\COM.SYS(3,3e8,5). COM Port 3 IRQ5.
>
>I figured that it should be okay to use IRQ5 since there is no sound card
>installed on this computer.
>
>I am fairly sure this means that I need to load a driver for this modem.
This
>however is a first for me.  I have never had to load a driver for a modem
>before.  All of the other modem that I installed worked without having to
load
>anything.  Maybe it's because this modem has Plug and Play capability.  This
is
>the Name, Type and Model number of the modem that I installed.
>
>    Name & Type.
>        ACCURA Hayes 33.6 Internal modem
>    These numbers were taken off of the back of the modem.
>        Acc336
>        5636US
>        V1.510
>
>The modem did come with a diskette that had device drivers but none of them
>were for OS/2.  There was one written for windows 3.1 that I tried to load
for
>WIN-OS/2 thinking that I could just set it all up under WIN-OS/2 but I kept
>getting an error messages when I tried to install it.
>
>
>So here's my question or questions.
>    1    Am I correct in thinking that this error message means
>        that I need to load a driver?

Unless it's a WinModem you don't need any device drivers.

Just get hold of a terminal emulator/comms program such as TE/2.

Start it up, and after set up the com port, speed etc., type ATZ
and see if returns OK. If that works use the command to display
the modems current settings - ATI5 on a USR modem - not sure how
standard this is though... You'd need to consult your modem manual.

If this works, you know your computer is talking to your modem,
so you can then look at any problems you may have setting up the
dialer.



>    2    If I do need to load a driver in order for this modem
>to work, is there one available for OS/2?
>
>Of course any help that you could give me regarding this would be greatly
>appreciated.
>
>Thank you for taking the time to read this post.
>
>Sincerely,
>Steve Rulison
>

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Legend Internet Ltd (1:109/42)

+----------------------------------------------------------------------------+

+============================================================================+