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

                 Saturday, 20-Nov-1999 to Friday, 26-Nov-1999

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

From: dmcbride@no.tower.spam.to.org                     20-Nov-99 02:16:15
  To: All                                               20-Nov-99 03:28:01
Subj: Re: Perl @INC

From: "Darin McBride" <dmcbride@no.tower.spam.to.org>

On 19 Nov 1999 22:00:07 GMT, lyn@zolotek.REMOVE-SPAM.com wrote:

>On Fri, 19 Nov 1999 02:38:16, "Darin McBride" 
><dmcbride@no.tower.spam.to.org> wrote:
>
>> On 17 Nov 1999 18:55:02 GMT, lyn@zolotek.REMOVE-SPAM.com wrote:
>> 
>> 1. I run Apache 1.3.9 on OS/2, and don't have any such problem.  I have the
>> following line in my config.sys:
>> 
>> set PERLLIB_PREFIX=f:/perllib/lib;D:/LANG/PERLLIB/LIB
>
>This works fine for Powerweb and Apache 1.3.6 with this cgi script, 
>but not Apache 1.3.9 - either for me or for others with the same 
>script. Do you have any scripts which 'use' modules from the standard 
>perl distribution? 1.3.9 will run formmail.cgi (not even a cmd) quite 
>happily, as it has no 'use' or 'require' statements. 

Literally, the top of my "join.cmd" is:
==================
extproc perl -w

BEGIN
{
    unshift @INC, qw(d:/src/perl)
}

use Net::SMTP;
use CGI;
use cgiconstants;
use Date::Parse;

my $const = new cgiconstants;

my $q = new CGI;
=============

It works absosmurfly perfectly.  It does CGI stuff.  It does SMTP stuff.  It
retrieves my CGI constants.  It parses dates.  And everything under
"Apache/1.3.9 (OS/2)".

>I have 'set emxopt=-h1024' in config.sys 

I try to keep defaults for my system in general - I dislike adding stuff to
config.sys.  Besides, when I first started playing with Apache, I didn't want
to reboot the system just to get it going.  :-)

>Mine have 'extproc perl -S', then:
>require 5.002;
>use strict;
>use Socket;
>my $LINK_TIMEOUT = 45;
>my $LINK_PORT    = 7786;
>my $LINK_HOST    = 'localhost';
>my $ERROR_ACTION = "-notify";
>$ENV{PATH} = "/bin:/usr/bin";

This last line here may be questionable on OS/2...

>$ENV{IFS} = " ";
>
>I tried putting this BEGIN ..  into the script with e:/usr/bin/perl, 

Shouldn't you be @INC'luding the perllib directory?

>but it turned out to need the full path to strict.pm. Then it needed 
>the full path for socket.pm added, and then the full path for 
>config.pm. After all this it failed for a new reason: "premature end 
>of script headers ... ok= def:  connect: No route to host". The log 
>for the daemon (which this cgi connects with) had "Died in server 
>spawn: REQUEST_METHOD is not defined at <daemon>". This doesn't happen
>at all with v 1.3.6 or other servers. So ... I just booted Linux and 
>compiled a new Apache 1.3.9 and ran the same cgi, and got exactly the 
>same error. Hmm. So, I changed to Apache 1.3.6 in Linux and again got 
>the same error. Normally on Linux this runs a comiled C cgi, not perl.
>Now I'm back in OS/2, running this same perl cgi quite happily under 
>Apache 1.3.6 or Powerweb. Odd. Maybe I'll have to buy some books on C 
>and figure out what "blah: parameter has incomplete type" and "blah: 
>referenced from text segment" means prior to failing to compile the C 
>version of the cgi.  Or just give up on Apache 1.3.9. 


---
Disclaimer: unless explicitly mentioned otherwise, I do not speak
for the company I work for.



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

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

From: steve53_remove_this@earthlink.net                 14-Nov-99 10:53:04
  To: All                                               20-Nov-99 03:28:02
Subj: Re: Problem installing a modem on an OS/2 workstation

From: steve53_remove_this@earthlink.net

In <19991112153602.05576.00000465@ng-cq1.aol.com>, on 11/12/99 
   at 08:36 PM, sruli87202@aol.com (SRuli87202) said:

>When I click on the Dial button on the OS/2 Internet dialer, I get this
>error message:
>	PPP Driver Failure.
>	Connection ERROR

This is not really the correct newgroup to ask this question.  However, we
are usually pretty good at trouble shooting problems. :)

You've got several choices:

 - Turn on the Debug object and reviewed the log?
 - Test the modem from the command line (i.e echo ATH1 >com3, copy com3
con, etc.)
 - Test the modem using HALite from bonus pack

Any of the above should give you some more insight as to where the failure
is.

As others have mentioned, you do need to make sure it not a WinModem.

HTH,

Steven

--
---------------------------------------------------------------
Steven Levine <steve53removethis@earthlink.net>  MR2/ICE #10183 Warp4/FP11
---------------------------------------------------------------


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

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

From: someone@somewhere.com                             20-Nov-99 08:45:05
  To: All                                               20-Nov-99 05:17:24
Subj: Manually loaded DLL won't work?

From: someone@somewhere.com (Charles Cruden)

I've been trying to get the DosSmSetTitle function to work with a
dynamically loaded (as opposed to compile-time linked) DLL, and have
been having a hell of a time.  It's to the point now that the function
is called correctly, appears to have exactly the same values on the
stack as the linked version, but still will not work properly.  It
returns 57 instead of 0.  The code is:

#define INCL_DOSMODULEMGR
#include <os2.h>

...

void SetTitle(char *Title) {
#ifdef WORKS
  extern APIRET16 APIENTRY16 DosSmSetTitle(PSZ);

  if (Title)
    DosSmSetTitle(Title);
#endif

#ifdef DOESNT_WORK
  APIRET16 APIENTRY16 (*DosSmSetTitle)(PSZ);
  HMODULE SMModule;

  if (Title) {
    if (!DosLoadModule(NULL, 0, "SESMGR", &SMModule)) {
      if (!DosQueryProcAddr(SMModule, 0, 
          "DOSSMSETTITLE", (PFN *)&DosSmSetTitle))
        DosSmSetTitle(Title);
      DosFreeModule(SMModule);
    }
  }
#endif
}

If I link the SESMGR.DLL library directly to the executable and
#define WORKS, the program works fine and the console title is changed
properly.  If I #define DOESNT_WORK and don't link in the DLL, the
program runs fine but the session title isn't changed.  I've debugged
the code, and DosSmSetTitle is being called in each case: it just
doesn't work in the second case.  Any ideas why?

The programs are being compiled/linked with Watcom 10.6 using a 32-bit
flat memory model.

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

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

From: no.spam@no.spam.org                               20-Nov-99 11:45:09
  To: All                                               20-Nov-99 10:33:15
Subj: Re: Problems when handling WM_PAINT in a second thread

From: "Cornelis Bockem?hl" <no.spam@no.spam.org>

Now I tried a bit, but not yet really successfully... see below...

On Mon, 15 Nov 1999 07:38:47 GMT, cbzh@my-deja.com wrote:

>In article <382D4580.5B88@ican.net>,
>  Peter Fitzsimons <pfitz@ican.net> wrote:
>> cbzh@my-deja.com 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
>>
>> You must call WinBegin/EndPaint() in the original thread, even if
>> painting occurs (slightly) later in the worker thread (the worker
>thread
>> has to query/maintain an HPS itself).  Are you doing this?  I've seen
>> other's caught by this trap.
>

[...my first reply removed...]

Now I went into it in my program. What's going on until now is:

- The main thread creates a HPS ("normal PS" using WinCreatePS())
when the main window is created. This is not destroyed any more until
the window is closed.

- If a WM_PAINT message arrives, this is passed further to a special
painting thread for doing the painting. It starts with ResetPS(). It
sets a semaphore to indicate that painting is busy.

- If another WM_PAINT arrives, it checks the semaphore and if it is
"busy", it calls StopPaint() with the HPS. Because the painting
thread checks that regularly, it stops prematurely if it is set.

- Once painting is stopped (semaphore), the second WM_PAINT is passed
to the painting thread in turn, etc.

This works so far ok, except for the strange resizing problems that
sometimes occur.

The first remedy was to catch the WM_SIZE messages of the frame
window, again set a semaphore indicating "resizing in progress" and
just don't pass the WM_PAINT messages further while this is the case.
Then after resizing is finished, the semaphore is cleared and another
the window is invalidated (i.e. another WM_PAINT). Most of the time
this works, but still not always.

Now I followed your advice and put calls to
WinBeginPaint()/WinEndPaint() (with the "global HPS" as parameter)
into the main thread code always before the WM_PAINT is posted to the
painting thread and always if this has finished working, i.e. if the
semaphore is ready (after an interruption) or if a special message is
posted back (normal termination).

BUT NOW: No effect so far! Everything still works, but with the same
problems.

One point could still be that I need to use two different HPS handles
for the two threads?! I will certainly try that. Do I have to create
them in their respective threads or may I create them both in the
main thread? Should I better replace the StopPaint() calls with the
HPS with another semaphore? ...

So still many questions and things to try - and still grateful for
any advice and experiences!

Greetings,
Cornelis Bockemhl <cbockem@datacomm.ch>
Author of "PmAs - Astronomy for the Presentation Manager"
http://www.datacomm.ch/cobo


--------------------------------------------
Cornelis Bockemhl, Dornach, Switzerland
e-mail: cbockem AT datacomm DOT ch
(use this instead of antispam reply address)
PGP public key available



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

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

From: dholmes@trellis.net                               21-Nov-99 00:39:29
  To: All                                               20-Nov-99 18:58:10
Subj: Re: Getting Started...

From: Dan Holmes <dholmes@trellis.net>

I bought two books from Amazon.  OS2 Warp programming for Dummies and
The Art of OS2 Warp Programming.  Both books are very good.  Check EDM
for their recommendations.

skrise@attglobal.net wrote:
> 
> I want to get involved in some of the exciting
> online OS/2 development projects, but have no
> experience doing OS/2 specific programming.
> 
> What books or online resources would be recommended
> as definitive guides to general OS/2 programming?
> 
> Thanks,
> Steven
> --
> Abstainer: a weak person who yields
>            to the temptation of denying himself a pleasure.
>            ... Ambrose Bierce

-- 
----------
dan holmes
mailto:dholmes@trellis.net
http://www.geocities.com/heartland/hollow/3097

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

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

From: dmcbride@no.tower.spam.to.org                     20-Nov-99 19:56:26
  To: All                                               21-Nov-99 02:58:01
Subj: Re: Perl @INC

From: "Darin McBride" <dmcbride@no.tower.spam.to.org>

On 20 Nov 1999 19:34:27 GMT, Ilya Zakharevich wrote:

>[A complimentary Cc of this posting was sent to Darin McBride
><dmcbride@no.tower.spam.to.org>],
>who wrote in article
<qzpoevqrgbjregbbet.flh4zi3.pminews@news.mtag1.on.wave.home.com>:
>> Shouldn't you be @INC'luding the perllib directory?
>
>Doubtful.  See the trailer of perl -V for `why'.  But changing @INC to
>this list (without '.') will help.

I was just meaning that if the guy was having a problem with perllib not
being there, wouldn't that be the directory to include, rather than the perl
directory itself?

---
Disclaimer: unless explicitly mentioned otherwise, I do not speak
for the company I work for.



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

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

From: hubert@ugrad.cs.ualberta.ca                       20-Nov-99 15:24:04
  To: All                                               21-Nov-99 02:58:01
Subj: Re: Getting Started...

From: Hubert Chan <hubert@ugrad.cs.ualberta.ca>

On Fri, 19 Nov 1999 skrise@attglobal.net wrote:

> I want to get involved in some of the exciting
> online OS/2 development projects, but have no
> experience doing OS/2 specific programming.
> 
> What books or online resources would be recommended
> as definitive guides to general OS/2 programming?
If you want to do Presentation Manager programming (as opposed to pure
text-based VIO), the book I use, which I have found very useful, is OS/2
Presentation Manager Programming by Charles Petzold.  It is a bit old,
since it was published in 1994, so it doesn't have any of the newer stuff
like DIVE, but I've found it to be very good for everything that I've
done.

Hubert.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Computing Science, U of Alberta, Edmonton, Canada
(1:109/42)

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

From: lyn@zolotek.REMOVE-SPAM.com                       20-Nov-99 23:48:09
  To: All                                               21-Nov-99 02:58:02
Subj: Re: Perl @INC

From: lyn@zolotek.REMOVE-SPAM.com

On Sat, 20 Nov 1999 22:05:17, ilya@math.ohio-state.edu (Ilya 
Zakharevich) wrote:
[posted and mailed]
> [A complimentary Cc of this posting was sent to Darin McBride
> <dmcbride@no.tower.spam.to.org>],
> who wrote in article
<qzpoevqrgbjregbbet.flii2t0.pminews@news.mtag1.on.wave.home.com>:
> > >> Shouldn't you be @INC'luding the perllib directory?
> > >
> > >Doubtful.  See the trailer of perl -V for `why'.  But changing @INC to
> > >this list (without '.') will help.
> > 
> > I was just meaning that if the guy was having a problem with perllib not
> > being there, wouldn't that be the directory to include, rather than the
perl
> > directory itself?
> 
> Well, I have no idea what is "the perl directory itself".  ;-)
> 
> It always makes sense to keep privately developed stuff in a separate
> directory.  Sometimes it also makes sense to have it in @INC.  ;-)
> 
> Ilya

To add a little to the saga, I just found this in config.sys for 
Aurora (which I don't use, as it makes the ext2fs driver blind):
REM *PERL INTERPRETER* SET 
PERLLIB_PREFIX=F:/PERLLIB/LIB;E:\USR\BIN\PERLLIB\LIB

SET 
PERLLIB=E:\USR\BIN\PERLLIB\LIB\SITE_PERL\OS2;E:\USR\BIN\PERLLIB\LIB\SI
TE_PERL

So I booted Aurora to see, but there was no difference in the cgi 
behaviour. I then edited the new line to point to the directories 
needed, and this put these into @INC. Also had to add more (including 
the directory for the daemon) into the cgi with BEGIN unshift .. , and
ended up with 6 in the cgi and then found that the daemon needed 
another 3 added (from its own private libs) before they were all in 
@INC. Then, and this is interesting, the errors were: "Too many open 
files: unable to open a file descriptor above 15, you may need to 
increase the number of descriptors". Started Apache 1.3.6 instead, 
which gave this error: "Too many open files: accept: (client socket) 
. OS2SEM: Error 105 getting accept lock. Exiting". So, under Aurora 
neither Apache will work properly with this perl package. Went back to
Warp 4 and Apache 1.3.6 worked properly (though it can't set locales) 
and 1.3.9 still failed totally. But, Powerweb runs perfectly with no 
errors of any sort at all. 

Tell you what though Darin, if you're certain that 1.3.9 "works 
absosmurfly perfectly", then grab the latest tar.gz from minivend.com 
and get it to run. Installation is simple enough - you just need to 
edit the OS sniffer in a few files. If you can get this to run, then 
there are a few people besides myself who will be very quick with 
congratulations. Be warned though that it's quite complex - the daemon
is 3,200 lines, and it has another 37 of its own libs (plus a few 
dozen config and other files). The author does say that this "pushes 
perl to its limits".

Cheers
Lyn 

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

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

From: pfitz@ican.net                                    21-Nov-99 03:52:06
  To: All                                               21-Nov-99 02:58:02
Subj: Re: Manually loaded DLL won't work?

From: Peter Fitzsimons <pfitz@ican.net>

Charles Cruden wrote:
> 
> I've been trying to get the DosSmSetTitle function to work with a
> dynamically loaded (as opposed to compile-time linked) DLL, and have
> been having a hell of a time.  It's to the point now that the function
> is called correctly, appears to have exactly the same values on the
> stack as the linked version, but still will not work properly.  It
> returns 57 instead of 0.  The code is:
> 
> #define INCL_DOSMODULEMGR
> #include <os2.h>
> 
> ...
> 
> void SetTitle(char *Title) {
> #ifdef WORKS
>   extern APIRET16 APIENTRY16 DosSmSetTitle(PSZ);
> 
>   if (Title)
>     DosSmSetTitle(Title);
> #endif
> 
> #ifdef DOESNT_WORK
>   APIRET16 APIENTRY16 (*DosSmSetTitle)(PSZ);
>   HMODULE SMModule;
> 
>   if (Title) {
>     if (!DosLoadModule(NULL, 0, "SESMGR", &SMModule)) {
>       if (!DosQueryProcAddr(SMModule, 0,
>           "DOSSMSETTITLE", (PFN *)&DosSmSetTitle))
>         DosSmSetTitle(Title);
>       DosFreeModule(SMModule);
>     }
>   }
> #endif
> }
> 

I still have watcom 10.6 installed, so I gave it a try.  sesmgr.dll is
full of fwd'ers (so IMPLIB can't make a *.lib from it), and I couldn't
find where it's been forwarded to (in the 10 mins I allowed myself for
this note :).

So I used WinSetTitle() instead.  You might also be interested in the
function "WinSetTitleAndIcon". This code works fine here both ways:

#define INCL_DOSMODULEMGR
#include <os2.h>


void SetTitle(char *Title) {
#ifdef WORKS
  extern APIRET16 APIENTRY16 WinSetTitle(PSZ); // WINSETTITLE =
PMSHAPI.93 (it's fwd'd to pmmerge in later os/2's)

  if (Title)
    WinSetTitle(Title);
#else
  APIRET16 APIENTRY16 (*WinSetTitle)(PSZ);
  HMODULE SMModule;

  if (Title) {
    if (!DosLoadModule(NULL, 0, "PMSHAPI", &SMModule)) {
      if (!DosQueryProcAddr(SMModule, 0,
	  "WINSETTITLE", (PFN *)&DosSmSetTitle))
	WinSetTitle(Title);
      DosFreeModule(SMModule);
    }
  }
#endif
}

int main(void)
{
    SetTitle("boo");
    getch();
    return 0;
}

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

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

From: pfitz@ican.net                                    21-Nov-99 04:37:07
  To: All                                               21-Nov-99 02:58:02
Subj: Re: Manually loaded DLL won't work?

From: Peter Fitzsimons <pfitz@ican.net>

Oops, I forgot to #under WORKS. My code doesn't work either through the
16bit function pointer,  with Watcom 10.6 or 11.0b.  

It works fine with IBM V3.  I have found other bugs with watcom's 16bit
support.  Do you have ibm's compiler?  Write a small dll in IBM to be
called from Watcom.

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

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

From: pfitz@ican.net                                    21-Nov-99 04:34:09
  To: All                                               21-Nov-99 02:58:02
Subj: Re: Problems when handling WM_PAINT in a second thread

From: Peter Fitzsimons <pfitz@ican.net>

> Now I followed your advice and put calls to
> WinBeginPaint()/WinEndPaint() (with the "global HPS" as parameter)

I hope that's not what I suggested (wrt to the global hps).  You should
use the HPS WinBeginPaint creates, since your other hps (the "real" one)
is in use.  Here's a better idea:

 case WM_PAINT:
	// do stuff to set up "paint thread"
        // do not do anything to the hps
        // do not call WinBegin/Endpaint, instead:
        return (MRESULT)TRUE;		// instead of the usual FALSE.

I don't know if this will solve your problem, but it is (one) correct
way to handle 2nd thread painting.

Another point.  WM_SIZE is sent after the window has already been
resized. If you need an earlier call to start/stop things, checkout
WM_WINTRACKFRAME.

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

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

From: karen_c_ro@hotmail.com                            21-Nov-99 12:06:14
  To: All                                               21-Nov-99 02:58:02
Subj: Re: Help for OS/2 users

From: "Karen" <karen_c_ro@hotmail.com>

Thanks, it's really a good place.

Kelvin



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

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

From: ilya@math.ohio-state.edu                          21-Nov-99 05:33:20
  To: All                                               21-Nov-99 02:58:02
Subj: Re: Manually loaded DLL won't work?

From: ilya@math.ohio-state.edu (Ilya Zakharevich)

[A complimentary Cc of this posting was sent to Peter Fitzsimons 
<pfitz@ican.net>],
who wrote in article <38376C6F.759B@ican.net>:
> I still have watcom 10.6 installed, so I gave it a try.  sesmgr.dll is
> full of fwd'ers (so IMPLIB can't make a *.lib from it), and I couldn't
> find where it's been forwarded to (in the 10 mins I allowed myself for
> this note :).

Oups, I mixed ifdef/ifndef's.  In fact the code which I posted is
marked as #if DOES_NOT_WORK.  Basically, I tried the same, but failed too...

BTW, I can see that the newer File Commander finally has *reliable*
process table switch.  How does it do it?  Is it morphing itself to
PM, then operating over the titlebar window directly?

Ilya

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Department of Mathematics, The Ohio State Univers
(1:109/42)

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

From: ilya@math.ohio-state.edu                          21-Nov-99 05:08:23
  To: All                                               21-Nov-99 05:24:19
Subj: Re: Perl @INC

From: ilya@math.ohio-state.edu (Ilya Zakharevich)

[A complimentary Cc of this posting was sent to 
<lyn@zolotek.REMOVE-SPAM.com>],
who wrote in article <J8TqGkcvSg25-pn2-Cy1gsdd70Txc@localhost>:
> To add a little to the saga, I just found this in config.sys for 

You sent a mail Cc of this, which was not marked as being a Cc.
*Never* do it: mail comes first, and then I need to answer your
posting *again*.

> Aurora (which I don't use, as it makes the ext2fs driver blind):
> REM *PERL INTERPRETER* SET 
> PERLLIB_PREFIX=F:/PERLLIB/LIB;E:\USR\BIN\PERLLIB\LIB

This is wrong.  Most probably an effect of (brokenware) SoftInstaller
which uppercased this line.  The first part of PERLLIB_PREFIX should
match the a start of [compiled-in] @INC settings *exactly*.

Lowercase it.  For best results, you may want to change \ in the
second part to / too (some modules may process @INC entries
themselves, and they may expect to see / there).

Ilya

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Department of Mathematics, The Ohio State Univers
(1:109/42)

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

From: stefanj@gte.net                                   21-Nov-99 10:25:23
  To: All                                               21-Nov-99 10:40:10
Subj: Joystick Device Driver Contest Update #4

From: stefanj@gte.net (Jason Stefanovich)

The value of all the prizes for the winner is now over $200
and $35 for the runner up.
I have received information from 2 people that they
are working on or considering working on this project.

  I HAVE RECIEVED AN OFFER FROM A COMPANY FOR A 
DONATION OF AN AMMOUNT OVER $100.  THIS COMPANY WOULD LIKE TO KNOW IF
THERE ARE ANY PEOPLE WORKING ON THIS PROJECT BEFORE THEY PUT THEIR
MONEY DOWN.  IF YOU ARE WORKING ON THIS PROJECT PLEASE CONTACT ME AT
STEFANJ@GTE.NET 

 MAMERun Joystick Device Driver Contest.

What is it?

Write your own joystick device driver for OS/2 and you could win $100
plus valuable prizes and earn the respect and gratitude of OS/2
gamers around the world! With the many new games available and the
advance of game controllers there arises a need for a better 
joystick device driver than IBM's advanced joystick device driver. 
Support for new controller features, such as 8+ buttons, will greatly
enhance the OS/2 gaming experience for gamers as well as 
developers.

For rules and other information check out:

  http://home1.gte.net/stefanj/contest.htm 

I am looking for additional sponsors for this contest. If you would
like to contribute please go to: 

  http://home1.gte.net/stefanj/sponsor.htm 

Any questions can be sent to me at Stefanj@gte.net

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

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

From: no.spam@no.spam.org                               21-Nov-99 12:36:09
  To: All                                               21-Nov-99 10:40:11
Subj: Re: Problems when handling WM_PAINT in a second thread

From: "Cornelis Bockem?hl" <no.spam@no.spam.org>

On Sun, 21 Nov 1999 04:34:19 GMT, Peter Fitzsimons wrote:

>> Now I followed your advice and put calls to
>> WinBeginPaint()/WinEndPaint() (with the "global HPS" as parameter)
>
>I hope that's not what I suggested (wrt to the global hps).

No, not exactly: You suggested calling WinBegin/EndPaint() in the
main thread, and I was just trying out if I could do it with the
"global hps" as a parameter, but intended to try creating a second
one as my next step - assuming that this was the really meant
approach!

  You should
>use the HPS WinBeginPaint creates, since your other hps (the "real" one)
>is in use.  Here's a better idea:
>
> case WM_PAINT:
>	// do stuff to set up "paint thread"

i.e.: Just post a message to that thread... (?!)

>        // do not do anything to the hps

...so better no "StopPaint()" calls (?!) I would have to try the
semaphore solution...

>        // do not call WinBegin/Endpaint, instead:
>        return (MRESULT)TRUE;		// instead of the usual FALSE.

ok, I will give that a try as well!

>
>I don't know if this will solve your problem, but it is (one) correct
>way to handle 2nd thread painting.

I searched the docs a lot about correct and uncorrect ways to do it,
but I didn't find anything very precise. There is e.g. a possible
error return from GPI functions saying that "another thread is doing
things at the same time with the same HPS", so I assumed that a HPS
is not necessarily something that cannot be shared between threads as
long as only one of them actually uses it at any one time...

>Another point.  WM_SIZE is sent after the window has already been
>resized. If you need an earlier call to start/stop things, checkout
>WM_WINTRACKFRAME.

Sorry, I didn't think when I wrote that: I actually checked first
what messages are being sent and - if I remember right - either
caught the WM_WINTRACKFRAME ore one of the MOUSEUP/DOWN messages
somehow: I don't have the source present here right now! At least it
works most of the time improved many things...

In the best case I would hope to be able to throw away all this
workaround code finally!

If all the other versions fail, I will try painting into a bitmap and
copy that to the window from the main thread: This might also have
other advantages, but is a bit more complicated to integrate in the
already existing code. I assume this should solve the threading
problems as well, because each HPS is strictly owned and used by only
one thread!

Thanks for your assistance - you seem to have experiences in the area
as well?!

Greetings,
Cornelis Bockemhl <cbockem@datacomm.ch>

--------------------------------------------
Cornelis Bockemhl, Dornach, Switzerland
e-mail: cbockem AT datacomm DOT ch
(use this instead of antispam reply address)
PGP public key available



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

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

From: djn@peninsula.hotkey.net.au                       21-Nov-99 15:50:17
  To: All                                               22-Nov-99 10:32:07
Subj: Re: Problems when handling WM_PAINT in a second thread

From: <djn@peninsula.hotkey.net.au>

On Sat, 20 Nov 1999 11:45:19 +0100 (CET), Cornelis Bockemhl wrote:

>Now I tried a bit, but not yet really successfully... see below...
>
>On Mon, 15 Nov 1999 07:38:47 GMT, cbzh@my-deja.com wrote:
>
>>In article <382D4580.5B88@ican.net>,
>>  Peter Fitzsimons <pfitz@ican.net> wrote:
>>> cbzh@my-deja.com 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
>>>
>>> You must call WinBegin/EndPaint() in the original thread, even if
>>> painting occurs (slightly) later in the worker thread (the worker
>>thread
>>> has to query/maintain an HPS itself).  Are you doing this?  I've seen
>>> other's caught by this trap.
>>
>
>[...my first reply removed...]
>
>Now I went into it in my program. What's going on until now is:
>
>- The main thread creates a HPS ("normal PS" using WinCreatePS())
>when the main window is created. This is not destroyed any more until
>the window is closed.
>
>- If a WM_PAINT message arrives, this is passed further to a special
>painting thread for doing the painting. It starts with ResetPS(). It
>sets a semaphore to indicate that painting is busy.
>
>- If another WM_PAINT arrives, it checks the semaphore and if it is
>"busy", it calls StopPaint() with the HPS. Because the painting
>thread checks that regularly, it stops prematurely if it is set.
>
>- Once painting is stopped (semaphore), the second WM_PAINT is passed
>to the painting thread in turn, etc.
>
>This works so far ok, except for the strange resizing problems that
>sometimes occur.
>
>The first remedy was to catch the WM_SIZE messages of the frame
>window, again set a semaphore indicating "resizing in progress" and
>just don't pass the WM_PAINT messages further while this is the case.
>Then after resizing is finished, the semaphore is cleared and another
>the window is invalidated (i.e. another WM_PAINT). Most of the time
>this works, but still not always.
>
>Now I followed your advice and put calls to
>WinBeginPaint()/WinEndPaint() (with the "global HPS" as parameter)
>into the main thread code always before the WM_PAINT is posted to the
>painting thread and always if this has finished working, i.e. if the
>semaphore is ready (after an interruption) or if a special message is
>posted back (normal termination).
>
>BUT NOW: No effect so far! Everything still works, but with the same
>problems.
>
>One point could still be that I need to use two different HPS handles
>for the two threads?! I will certainly try that. Do I have to create
>them in their respective threads or may I create them both in the
>main thread? Should I better replace the StopPaint() calls with the
>HPS with another semaphore? ...
>
>So still many questions and things to try - and still grateful for
>any advice and experiences!
>
>Greetings,
>Cornelis Bockemhl <cbockem@datacomm.ch>
>Author of "PmAs - Astronomy for the Presentation Manager"
>http://www.datacomm.ch/cobo
>
>
>--------------------------------------------
>Cornelis Bockemhl, Dornach, Switzerland
>e-mail: cbockem AT datacomm DOT ch
>(use this instead of antispam reply address)
>PGP public key available
>
>
>
>
Try going to http://www.lesbell.com.au
You will find an OS/2 course there
Look at the article on Model View Control
In there there is two ways of implementing a second thread window 
painting scheme.

A full explination of why you need to call WinBeginPaint in the 
WM_PAINT message handeling is provided as well as working sample code.

I would be surprised if you would need more info than what is included 
in this article.

Regards Dennis.

I had intended to send you a copy of the article but when you 
deliberately make it difficult for me to reply by havinf a fictional 
reply to address I usualy say stuff them and just do nothing.



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Customer of Connect.com.au Pty. Ltd. (1:109/42)

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

From: djn@peninsula.hotkey.net.au                       21-Nov-99 15:55:03
  To: All                                               22-Nov-99 10:32:07
Subj: Re: Manually loaded DLL won't work?

From: <djn@peninsula.hotkey.net.au>

On Sat, 20 Nov 1999 08:45:11 GMT, Charles Cruden wrote:

>I've been trying to get the DosSmSetTitle function to work with a
>dynamically loaded (as opposed to compile-time linked) DLL, and have
>been having a hell of a time.  It's to the point now that the function
>is called correctly, appears to have exactly the same values on the
>stack as the linked version, but still will not work properly.  It
>returns 57 instead of 0.  The code is:
>
>#define INCL_DOSMODULEMGR
>#include <os2.h>
>
>...
>
>void SetTitle(char *Title) {
>#ifdef WORKS
>  extern APIRET16 APIENTRY16 DosSmSetTitle(PSZ);
>
>  if (Title)
>    DosSmSetTitle(Title);
>#endif
>
>#ifdef DOESNT_WORK
>  APIRET16 APIENTRY16 (*DosSmSetTitle)(PSZ);
>  HMODULE SMModule;
>
>  if (Title) {
>    if (!DosLoadModule(NULL, 0, "SESMGR", &SMModule)) {
>      if (!DosQueryProcAddr(SMModule, 0, 
>          "DOSSMSETTITLE", (PFN *)&DosSmSetTitle))
>        DosSmSetTitle(Title);
>      DosFreeModule(SMModule);
>    }
>  }
>#endif
>}
>
>If I link the SESMGR.DLL library directly to the executable and
>#define WORKS, the program works fine and the console title is changed
>properly.  If I #define DOESNT_WORK and don't link in the DLL, the
>program runs fine but the session title isn't changed.  I've debugged
>the code, and DosSmSetTitle is being called in each case: it just
>doesn't work in the second case.  Any ideas why?
>
>The programs are being compiled/linked with Watcom 10.6 using a 32-bit
>flat memory model.
>
>
I seem to recall that you need to include the ".dll" extension.

so try if (!DosLoadModule(NULL, 0, "SESMGR.DLL", &SMModule)) {

and see if it works better.

regards Dennis.


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Customer of Connect.com.au Pty. Ltd. (1:109/42)

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

From: ocpnrv@trespass.net                               22-Nov-99 09:28:04
  To: All                                               22-Nov-99 10:32:07
Subj: homework help  3734

From: ocpnrv@trespass.net

http://home.att.net/~troy.lilly/otwrldelec.htm
Please post this in your news group.
Visit our Free Website dedicated to free internet education and electronics
and computer engineering. This free unique resource is maintained and
consistantly updated by a group of 4.0 electronics & Computer engineering
graduates and Certified electronic technicians as well as internet webmasters. 
    Enjoy your free education!!!
http://home.beseen.com/technology/twayne01/index.htm
ldutcxnhklzfddhlhydbcbusjruecsfjgzejycmys

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

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

From: csaba_r@my-deja.com                               22-Nov-99 14:38:23
  To: All                                               22-Nov-99 21:38:28
Subj: Re: Perl @INC

From: csaba_r@my-deja.com (Csaba Raduly)

lyn@zolotek.REMOVE-SPAM.com wrote in <J8TqGkcvSg25-pn2
-Cy1gsdd70Txc@localhost>: 

>On Sat, 20 Nov 1999 22:05:17, ilya@math.ohio-state.edu (Ilya 
>Zakharevich) wrote:
[snip]>
>So I booted Aurora to see, but there was no difference in the cgi 
>behaviour. I then edited the new line to point to the directories 
>needed, and this put these into @INC. Also had to add more (including 
>the directory for the daemon) into the cgi with BEGIN unshift .. , and
>ended up with 6 in the cgi and then found that the daemon needed 
>another 3 added (from its own private libs) before they were all in 
>@INC. Then, and this is interesting, the errors were: "Too many open 
>files: unable to open a file descriptor above 15, you may need to 
>increase the number of descriptors". Started Apache 1.3.6 instead, 
>which gave this error: "Too many open files: accept: (client socket) 
>. OS2SEM: Error 105 getting accept lock. Exiting". So, under Aurora 
>neither Apache will work properly with this perl package. Went back to
>Warp 4 and Apache 1.3.6 worked properly (though it can't set locales) 
>and 1.3.9 still failed totally. But, Powerweb runs perfectly with no 
>errors of any sort at all. 
>
[snip]

This may be an EMX problem. For an explanation and a patch, go to 
http://silk.apana.org.au/apache/emx_patched.README.txt
(or download http://silk.apana.org.au/apache/emx_patched.zip)

Csaba
-- 
-----BEGIN GEEK CODE BLOCK----- 
Version 3.1
GCS/MU d- s:- a30 C++$ UL+ P+>+++ L++ E- W+ N++ o? K? w++>$ O++$ M-
V- PS PE Y PGP- t+ 5 X++ R* tv++ b++ DI+++ D++ G- e+++ h-- r-- !y+
-----END GEEK CODE BLOCK----- 

Csaba Raduly,    Software Developer (OS/2),    Sophos Anti-Virus
mailto:csaba.raduly@sophos.com            http://www.sophos.com/
US Support +1 888 SOPHOS 9            UK Support +44 1235 559933
Life is complex, with real and imaginary parts.

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

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

From: nospam_ktk@netlabs.org                            22-Nov-99 23:50:22
  To: All                                               22-Nov-99 21:38:29
Subj: Re: Getting Started...

From: "Adrian Gschwend" <nospam_ktk@netlabs.org>

On Fri, 19 Nov 1999 15:32:53 -0500, skrise@attglobal.net wrote:

>What books or online resources would be recommended
>as definitive guides to general OS/2 programming?

http://www.netlabs.org/devcorner/ (will be updated soon)

Also check existing sourcecode at OS/2 Netlabs in general, we also have some
very nice stuff at our CVS servers (go to http://www.netlabs.org/nosa/). You
can learn a lot from existing code

cu

Adrian



---
Adrian Gschwend
@ OS/2 Netlabs

ICQ: 22419590
ktk@netlabs.org
-------
The OS/2 OpenSource Project:
http://www.netlabs.org


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

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

From: bv@opera.no                                       23-Nov-99 21:48:28
  To: All                                               23-Nov-99 16:44:03
Subj: Re: os2  Warp 4 Install problem

From: =?iso-8859-1?Q?Bj=F8rn?= Vermo <bv@opera.no>

Neil wrote:

> Can anyone help my poor system administrator, he's trying to install os2
> warp4.The package consist of 4 cd's and 3 disks (dutch version) and at the
> end of the install it asks for the "Introduction disk" to be inserted in
> drive a.

4 CDs for Warp 4? I installed it from one (a long time ago), and I do not
think you need anything more. The others are extras you can add after
installation if you want them.

>
> We have tried creating new install disks but it still asks for the
> "Introduction disk" after the first reboot in the installation. Are we
> missing a disk or is this a known bug?

I guess this must be a poor translation. You need three diskettes and one CD
to do the installation. The bootable diskette should be labeled "Installation
diskette", and I suppose that is the one the system is asking for. The others
are "Diskette 1" and "Diskette 2". Unless there is a problem with your
hardware, this should be what you boot from after the drive has been prepared
for installation by FDISK. Do NOT choose "easy installation" or whatever it is
called. Make a suitable boot partition (some 200-300 MB) and format it as
HPFS, leave the rest of the drive as one partition for data and applications
(also to be formatted as HPFS).

If the CD-ROM drive is not supported out of the box, or if the disk you
install to is not a SCSI drive and bigger than 2GB, you will need to get one
or more updated device drivers. The Warp 4 install program has been known to
give wrong error messages when it cannot deal with the disk or CD-ROM drives.


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

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

From: Trevor-Hemsley@dial.pipex.com                     23-Nov-99 21:14:03
  To: All                                               23-Nov-99 19:58:05
Subj: Re: os2  Warp 4 Install problem

From: "Trevor Hemsley" <Trevor-Hemsley@dial.pipex.com>

On Tue, 23 Nov 1999 16:30:45 +0100, Neil wrote:

->Can anyone help my poor system administrator, he's trying to install os2
->warp4.The package consist of 4 cd's and 3 disks (dutch version) and at the
->end of the install it asks for the "Introduction disk" to be inserted in
->drive a.
->We have tried creating new install disks but it still asks for the
->"Introduction disk" after the first reboot in the installation. Are we
->missing a disk or is this a known bug?
->We tried IBM but they were usless...

If you have SET COPYFROMFLOPPY=1 set in CONFIG.SYS then it will ask for
the first two diskettes to be reinserted at the end of the first phase of
the install. This is so that it can copy the updated drivers from them to
the HD. If memory serves it asks for them in reverse order, so diskette #1
then #0 (aka the install diskette).


Trevor Hemsley, London, UK
(Trevor-Hemsley@dial.pipex.com or 75704.2477@compuserve.com)



--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: UUNET WorldCom server (post doesn't reflect views
(1:109/42)

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

From: lyn@zolotek.REMOVE.com                            23-Nov-99 23:45:20
  To: All                                               23-Nov-99 21:19:15
Subj: Re: Perl @INC

From: lyn@zolotek.REMOVE.com (Lyn St George)

[ ** POSTED AND MAILED ** ]

On Tue, 23 Nov 1999 13:01:20, bh@silk.apana.org.au (Brian Havard) 
wrote:

> lyn@zolotek.REMOVE-SPAM.com writes:
> 
> >Hallo - this may well be considered a dumb question, but I really_need
> >the answer and so far it has totally escaped me. As Apache 1.3.9 no 
> >longer honours the 'redirect' setting in config.sys for f:/perllib 
> >..;e:\usr\bin\perllib ... , I need to add e:/usr/bin/perllib/lib into
> >@INC manually. I have RTFM but can't see how to apply the brief n

[snip]

> Add to your httpd.conf
> PassEnv PERLLIB_PREFIX

Hmm. This certainly passes the environment through all right. If I run
the cgi as foo.cmd then the only error recorded is "premature end 
script headers", but if it is run as foo.cgi, then the other errors 
are (double spaced for clarity):

"Use of uninitialized value at 
e:/usr/bin/perllib/lib/5.00553/os2/Socket.pm line 278."

which is:  pack_sockaddr_in(@_);

then: "Use of uninitialized value at foo.cgi line 157"

which is: socket(SOCK, AF_INET, SOCK_STREAM, $proto) or die "socket: 
$!\n";

then: "Use of uninitialized value at foo.cgi line 166"

which is: die "ok=$ok def: $def connect: $!\n" if ! $ok;

then: "ok= def:  connect: No route to host"

This is under Warp 4fp6, emx0.9d, perl5.00553. I replaced emx.dll with
the patched one as Csaba Raduly suggested, though this made no 
difference in itself under Aurora.  This cgi runs correctly under 
Apache136 or Powerweb, and I know of others with the same problem 
under Apache 139. 

Could someone verify one thing (which *seems* obvious): if I run the C
version of this cgi to connect to the perl daemon (instead of the perl
cgi), then Apache is completely out of the loop WRT perl? The rest of 
the perl package should still find its environment OK, and Apache is 
only unsetting it for itself and not the daemon and its libs? If so, 
then I'll knuckle down and see what needs to be fixed to get the C to 
compile. 


Cheers
Lyn 

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

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

From: cbzh@my-deja.com                                  24-Nov-99 08:44:11
  To: All                                               24-Nov-99 05:20:20
Subj: Re: Problems when handling WM_PAINT in a second thread

From: cbzh@my-deja.com

In article <81b90j$olu$1@nnrp1.deja.com>,
  cbzh@my-deja.com wrote:
> In article <81arvu$rv$1@perki.connect.com.au>,
>   <djn@peninsula.hotkey.net.au> wrote:
> > On Sat, 20 Nov 1999 11:45:19 +0100 (CET), Cornelis Bockemhl wrote:
> >
>
> [...]
>
> > Try going to http://www.lesbell.com.au
> > You will find an OS/2 course there
> > Look at the article on Model View Control
> > In there there is two ways of implementing a second thread window
> > painting scheme.
>
> Thanks a lot for the link: Looks like very interesting stuff indeed!

[...]

As a probably final remark I want to say _thank you_ to all those who
replied to my request - even if the outcome is still not what I would
like: Everything still exactly the same :-(

- The above link leads indeed to some interesting material, but going
into it I found out that almost everything is already implemented in my
program; the only omission I found was that I didn't call
WinInitialize() for the paint thread also, but this didn't change
anything visibly.

- I also followed the advices of Peter Fitzsimmons now completely (see
his postings in this thread): The HPS in which the paint thread paints
is now strictly "property of this thread", i.e. it is created, painted
to and destroyed there. The only thing that the main thread still does
with it is calling WinSetStopPaint() (maybe not the exact name?) in
order to stop painting, but replacing this with a semaphore only made
the reaction slower (which could be improved again, but I decided to
just switch back).

- I also followed the other part of Peter's advices: I tried returning
"TRUE" from the WM_PAINT message in the main thread after having
initiated the painting in the paint thread, and I tried opening and
closing another HPS there with WinBegin/EndPaint() (which is never used
for painting). I made sure that opening occurs before the paint thread
starts painting (in his own HPS) and closing occurs after the paint
thread is ready (by posting back a message to the main thread).

- I didn't find the time yet to try the other possible solution
which Jerry Stuckle proposed: painting into a memory bitmap. I am
thinking about trying it, even if it is a bigger change than the other
things.

One thing to mention is that before and after all these changes the
program was fully functional; I actually created a lot of astronomical
graphics and maps with it already! What happens is e.g.: A graphic is
created, another window comes in front, I want to fetch it back by
clicking into the title bar - and it jumps at the same time to the lower
left corner of the screen, just the title bar still visible. I can then
drag it back on the screen... Another thing can happen when resizing the
window with the mouse: Afterwards the window is either like I wanted it
to be, or suddenly shrunk to just a small strip. I can then try to
enlarge it again with the mouse, and many times it stays then open,
otherwise I have to try again... This behaviour is different for
different drawings, but with one and the same more or less reproducible,
so I think it is really a timing problem between the two threads??!

Yesterday I also did two other tests:

- I removed OD1.52 and Xfolder (just disabled the classes by renaming
the directories) because I suspected them to be part of the problem -
but the same thing still happened exactly the same way.

- If I turn off the option "System"->"User Interface"->"Move whole
windows" (or however they are exactly called in english versions!) the
problems disappear completely(!!).

Greetings,
Cornelis Bockemhl <cbockem@datacomm.ch>
Author of "PmAs - Astronomy for the Presentation Manager"
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: ralf.schiwasinske@gmx.de                          24-Nov-99 22:44:06
  To: All                                               24-Nov-99 19:59:02
Subj: Re: Changing fontsize in OS/2 Window from rexx?

From: ralf.schiwasinske@gmx.de (Ralf Schiwasinske)

Niclas =?iso-8859-1?Q?Lindstr=F6m?= 
<niclas.lindstrom@edt.ericsson.se> wrote:

> How do I change the current font size for an OS/2 VIO Window from within
> a Rexx program..??

Maybe you could use something from VIOCLI.CMD:

/*
   Usage: VIOCLI height width command
     e.g. VIOCLI 20 12 dir

*/
parse arg height width command
FontMenuEntry = 'Schrif~tartgre...'
call rxFuncAdd 'SysIni', 'REXXUTIL', 'SysIni'
newFontSize = d2c(width)||d2c(height)
oldFontSize =  SysIni( 'USER', 'Shield', FontMenuEntry )
call SysIni 'USER', 'Shield', FontMenuEntry, newFontSize
'@start /win /C ' || command
call SysSleep 1
if oldFontSize <> 'ERROR:' then
     call SysIni 'USER', 'Shield', FontMenuEntry, oldFontSize
 else
     call SysIni 'USER', 'Shield', FontMenuEntry, 'DELETE:'
exit


Ralf 
-- 




--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Customer of UUNET Deutschland GmbH, Dortmund, Ger
(1:109/42)

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

From: ralf.schiwasinske@gmx.de                          24-Nov-99 22:54:28
  To: All                                               24-Nov-99 19:59:02
Subj: Re: Changing fontsize in OS/2 Window from rexx?

From: ralf.schiwasinske@gmx.de (Ralf Schiwasinske)

ralf.schiwasinske@gmx.de (Ralf Schiwasinske) wrote:

> Niclas =?iso-8859-1?Q?Lindstr=F6m?= 
> <niclas.lindstrom@edt.ericsson.se> wrote:
> 
> > How do I change the current font size for an OS/2 VIO Window from within
> > a Rexx program..??
> 
> Maybe you could use something from VIOCLI.CMD:

I don't want to neglect mentioning the source:
REXX Tips & Tricks by  Bernd Schemmer. 

Search hobbes for rxtt29.zip.

Ralf 
-- 




--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Customer of UUNET Deutschland GmbH, Dortmund, Ger
(1:109/42)

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

From: C.J.@btsoftware.com                               25-Nov-99 10:21:09
  To: All                                               25-Nov-99 10:37:25
Subj: Check out : HomePage Publisher

From: "C.J." <C.J.@btsoftware.com>

HomePage Publisher
***************************

HomePage Publisher is an integrated WYSIWYG HTML publisher and
editor/browser. HPP enables you to create or modify any HTML pages. Easy to
use, it does not require knowledge of HTML tags. With HPP, you will be able
to modify pages and images directly in your document.

Check it out and download the free trial version:
http://btsoftware.com/os2/hpp.htm


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

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

From: someone@somewhere.com                             25-Nov-99 10:34:17
  To: All                                               25-Nov-99 10:37:25
Subj: Re: Manually loaded DLL won't work?

From: someone@somewhere.com (Charles Cruden)

On Sun, 21 Nov 1999 04:37:15 GMT, Peter Fitzsimons <pfitz@ican.net>
wrote:

>Oops, I forgot to #under WORKS. My code doesn't work either through the
>16bit function pointer,  with Watcom 10.6 or 11.0b.  

Doh!

>It works fine with IBM V3.  I have found other bugs with watcom's 16bit
>support.  Do you have ibm's compiler?  Write a small dll in IBM to be
>called from Watcom.

I'm a student, so my budget pretty much only permits one compiler.  :)
Watcom 10.6 has stood me in pretty good stead so far, but I haven't
been able to find a way to kludge around it in this case....

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

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

From: someone@somewhere.com                             25-Nov-99 10:36:01
  To: All                                               25-Nov-99 10:37:25
Subj: Re: Manually loaded DLL won't work?

From: someone@somewhere.com (Charles Cruden)

On Sun, 21 Nov 1999 15:55:06 -1000, <djn@peninsula.hotkey.net.au>
wrote:

>I seem to recall that you need to include the ".dll" extension.
>
>so try if (!DosLoadModule(NULL, 0, "SESMGR.DLL", &SMModule)) {
>
>and see if it works better.

Made no difference, I'm afraid.

For the record, I don't think the .DLL is required: one would presume
that if it were, DosLoadModule would have returned an error.  In this
case it didn't.

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

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

From: someone@somewhere.com                             25-Nov-99 10:39:22
  To: All                                               25-Nov-99 10:37:25
Subj: Re: Manually loaded DLL won't work?

From: someone@somewhere.com (Charles Cruden)

On 24 Nov 1999 00:05:44 +1100, bh@silk.apana.org.au (Brian Havard)
wrote:

>someone@somewhere.com (Charles Cruden) writes:
>
>>The programs are being compiled/linked with Watcom 10.6 using a 32-bit
>>flat memory model.
>
>I found it works if you use the 16 bit version of DosQueryProcAddr(), 
>DosGetProcAddr(). As in (lifted from FC/2 source):
>
>extern APIRET16 APIENTRY16 (*winSetTitleAndIcon)( PSZ16, PSZ16 );
>...
>DosGetProcAddr( hPMSHAPI, (char *)MK_FP(0,ORD_WINSETTITLEANDICON),
&winSetTitleAndIcon ) 
>
>This is with Watcom C++ v11 

I tried this and found that DosGetProcAddr produced an undefined
symbol.  From the headers, it would seem it's only defined in the OS/2
2.1 os2.h: perhaps it's only available in a 16-bit object file?  How
did you get your example to compile in a 32-bit executable?

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

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

From: bh@silk.apana.org.au                              25-Nov-99 22:51:13
  To: All                                               25-Nov-99 10:37:25
Subj: Re: Perl @INC

From: bh@silk.apana.org.au (Brian Havard)

lyn@zolotek.REMOVE.com (Lyn St George) writes:

>On Tue, 23 Nov 1999 13:01:20, bh@silk.apana.org.au (Brian Havard) 
>wrote:

>> lyn@zolotek.REMOVE-SPAM.com writes:
>> 
>> >Hallo - this may well be considered a dumb question, but I really_need
>> >the answer and so far it has totally escaped me. As Apache 1.3.9 no 
>> >longer honours the 'redirect' setting in config.sys for f:/perllib 
>> >..;e:\usr\bin\perllib ... , I need to add e:/usr/bin/perllib/lib into
>> >@INC manually. I have RTFM but can't see how to apply the brief n

>[snip]

>> Add to your httpd.conf
>> PassEnv PERLLIB_PREFIX

>Hmm. This certainly passes the environment through all right. If I run
>the cgi as foo.cmd then the only error recorded is "premature end 
>script headers", but if it is run as foo.cgi, then the other errors 
>are (double spaced for clarity):

>"Use of uninitialized value at 
>e:/usr/bin/perllib/lib/5.00553/os2/Socket.pm line 278."

If your CGI does socket stuff you'll probably need
PassEnv ETC
as well.

Both of these tips and more are given on my Apache for OS/2
web page at http://silk.apana.org.au/apache/
-- 

______________________________________________________________________________
 | Brian Havard                   | "He is not the messiah!                  
|
 | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of Brian
|

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

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Australian Public Access Network Association (1:109/42)

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

From: info@bosman-water.nl                              25-Nov-99 15:13:27
  To: All                                               25-Nov-99 14:28:23
Subj: Re: Porting C++ Code from OS/2 Warp to Windows NT

From: "storkbos" <info@bosman-water.nl>

Does anyone know of a tool or set of tools which can be used to port
multiple applications written in C++ from OS/2 Warp to Windows NT?

E.A. Abalain
Bosman Watermanagement BV


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

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

From: stefanj@gte.net                                   25-Nov-99 20:20:09
  To: All                                               25-Nov-99 19:46:19
Subj: Joystick Device Driver Contest.....New Entries!!

From: stefanj@gte.net (Jason Stefanovich)

I have received a new entry from Vesa Jskelinen,
A Joystick driver that has support for the Gravis Gamepad Pro.
Also, check out Vesa's proposal for an extended joystick
standard under OS/2.



MAMERun Joystick Device Driver Contest.

What is it?

Write your own joystick device driver for OS/2 and you could win $100
plus valuable prizes and earn the respect and gratitude of OS/2
gamers around the world! With the many new games available and the
advance of game controllers there arises a need for a better 
joystick device driver than IBM's advanced joystick device driver. 
Support for new controller features, such as 8+ buttons, will greatly
enhance the OS/2 gaming experience for gamers as well as 
developers.

For rules and other information check out:

  http://home1.gte.net/stefanj/contest.htm 

I am looking for additional sponsors for this contest. If you would
like to contribute please go to: 

  http://home1.gte.net/stefanj/sponsor.htm 

Any questions can be sent to me at Stefanj@gte.net

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

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

From: lyn@zolotek.REMOVE.com                            25-Nov-99 22:19:21
  To: All                                               25-Nov-99 19:46:19
Subj: Re: Perl @INC

From: lyn@zolotek.REMOVE.com (Lyn St George)

On Thu, 25 Nov 1999 11:51:27, bh@silk.apana.org.au (Brian Havard) 
wrote:

[snip]
 
> If your CGI does socket stuff you'll probably need
> PassEnv ETC
> as well.

Aha! This got most of it to work, though now only for foo.cmd - 
foo.cgi reports: "socket: Protocol family not supported". The .cmd 
works on simple links, but once args are added, eg <a href 
.../foo.cmd/process/locale/ru_RU/page/index>, or < 
../foo.cmd/scan/sf=category/df=yes/ml=2/sp=resultsv/se=Victorian> 
then it again gets "prem end of script headers", and the minivend 
error log reports "undefined catalog 
/cgi-bin/foo.cmd/process/locale/ru_RU". I've set the environment for 
the private config, daemon and libs and added PassEnv .. for these, 
but no go. I'll keep working on this:)

Many thanks.
 
> Both of these tips and more are given on my Apache for OS/2
> web page at http://silk.apana.org.au/apache/
> -- 
> 
______________________________________________________________________________
>  | Brian Havard                   | "He is not the messiah!                  
 |
>  | brianh at kheldar.apana.org.au | He's a very naughty boy!" - Life of
Brian |
> 
------------------------------------------------------------------------------

Cheers
Lyn 

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

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

From: abuse@orac.clara.co.uk                            25-Nov-99 22:40:01
  To: All                                               25-Nov-99 19:46:19
Subj: Compiler bugs in VAC++ 3.0 FP8

From: abuse@orac.clara.co.uk (Paul Ratcliffe)

Hey, has anyone seen this bug before in VAC++ 3.0 with FP8. Try compiling it
using icc test.c and then icc /O test.c and running it:

test.c
------
#include <os2.h>
#include <string.h>
#include <stdio.h>

void PrintFSTopBorder(BOOL noLineChars)
{
    ULONG i;
    UCHAR lineBuff[81];
    UCHAR vertBar=179, horzBar=196, topLeftCorner=218,
          botLeftCorner=192, topRightCorner=191,
          botRightCorner=217, teeBarTop=194, teeBarBot=193,
          teeBarRight=180, teeBarLeft=195, crossBar=197;

    if (noLineChars)
        {
        vertBar='|'; horzBar='-'; topLeftCorner='/';
        botLeftCorner='\\'; topRightCorner='\\';
        botRightCorner='/'; teeBarTop='-'; teeBarBot='-';
        teeBarRight='|'; teeBarLeft='|'; crossBar='|';
        }

    memset(lineBuff, 0, sizeof(lineBuff));
    lineBuff[0]=topLeftCorner;
    for (i=1; i<14; i++)
        {
        lineBuff[i]=horzBar;
        }
    lineBuff[14]=teeBarTop;
    for (i=15; i<29; i++)
        {
        lineBuff[i]=horzBar;
        }
    lineBuff[29]=teeBarTop;
    for (i=30; i<47; i++)
        {
        lineBuff[i]=horzBar;
        }
    lineBuff[47]=topRightCorner;
    printf("\n%s\n", lineBuff);

    return;
}

void main(void)
{
    PrintFSTopBorder(0);
    PrintFSTopBorder(1);
}


If I make i volatile then the problem goes away, which seems fairly
reasonable.
If I comment out the if(noLineChars){ } bit then it also goes away.

Looking at the assembler output, it is just garbage with the original source
and
/O.
ISTR VAC++ 3.0 is still in service. Bet they won't fix it though...

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

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

From: pfitz@ican.net                                    26-Nov-99 00:29:21
  To: All                                               25-Nov-99 21:46:01
Subj: Re: Compiler bugs in VAC++ 3.0 FP8

From: Peter Fitzsimons <pfitz@ican.net>

Paul Ratcliffe wrote:
> 
> Hey, has anyone seen this bug before in VAC++ 3.0 with FP8. Try compiling it
> using icc test.c and then icc /O test.c and running it:
> 

It's reproducible here. same FP8.

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

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

From: retsiemynnaht@spammoc.beoohaygon...               25-Nov-99 23:56:21
  To: All                                               26-Nov-99 10:42:21
Subj: Re: Compiler bugs in VAC++ 3.0 FP8

Message sender: retsiemynnaht@spammoc.beoohaygone.net

From: "Mike Ruskai" <retsiemynnaht@spammoc.beoohaygone.net>

On Thu, 25 Nov 1999 22:40:03 GMT, Paul Ratcliffe wrote:

>Hey, has anyone seen this bug before in VAC++ 3.0 with FP8. Try compiling it
>using icc test.c and then icc /O test.c and running it:
>
>test.c
>------
>#include <os2.h>
>#include <string.h>
>#include <stdio.h>
>
>void PrintFSTopBorder(BOOL noLineChars)
>{
>    ULONG i;
>    UCHAR lineBuff[81];
>    UCHAR vertBar=179, horzBar=196, topLeftCorner=218,
>          botLeftCorner=192, topRightCorner=191,
>          botRightCorner=217, teeBarTop=194, teeBarBot=193,
>          teeBarRight=180, teeBarLeft=195, crossBar=197;
>
>    if (noLineChars)
>        {
>        vertBar='|'; horzBar='-'; topLeftCorner='/';
>        botLeftCorner='\\'; topRightCorner='\\';
>        botRightCorner='/'; teeBarTop='-'; teeBarBot='-';
>        teeBarRight='|'; teeBarLeft='|'; crossBar='|';
>        }
>
>    memset(lineBuff, 0, sizeof(lineBuff));
>    lineBuff[0]=topLeftCorner;
>    for (i=1; i<14; i++)
>        {
>        lineBuff[i]=horzBar;
>        }
>    lineBuff[14]=teeBarTop;
>    for (i=15; i<29; i++)
>        {
>        lineBuff[i]=horzBar;
>        }
>    lineBuff[29]=teeBarTop;
>    for (i=30; i<47; i++)
>        {
>        lineBuff[i]=horzBar;
>        }
>    lineBuff[47]=topRightCorner;
>    printf("\n%s\n", lineBuff);
>
>    return;
>}
>
>void main(void)
>{
>    PrintFSTopBorder(0);
>    PrintFSTopBorder(1);
>}
>
>
>If I make i volatile then the problem goes away, which seems fairly
reasonable.
>If I comment out the if(noLineChars){ } bit then it also goes away.
>
>Looking at the assembler output, it is just garbage with the original source
and
>/O.
>ISTR VAC++ 3.0 is still in service. Bet they won't fix it though...

Wacky.  I neglected to enable optimizations (leave them off for debugging)
when I compiled the above for release.  I just checked this (also using VACPP
3.08 here), and /Oc (compact optimization) presents no problems, but /O
(speed optimizations) does.

It breaks all of the functions like the one above.  The assembly looks like
loop unrolling gone awry, though I don't know enough assembly to see exactly
what's going on.

I'll report this to the VACPP newsgroup, but like you, I doubt they'll take
the time to fix it.


--
 - Mike

Remove 'spambegone.net' and reverse to send e-mail.


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

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

From: refkvj@hotmail.com                                26-Nov-99 06:17:15
  To: All                                               26-Nov-99 10:42:21
Subj: Very Special Report coming soon  6276

From: refkvj@hotmail.com

This is not spam. You are receiving this because you have sent me information
about your program or opportunity and I appreciate it. I would like to
reciprocate because many of you would like to retire, financially, within 6-9
months, as I will. 
 Let me keep it short and direct. I have extremely valuable information to
share with you. It involves a private club and wealth building along with
asset preservation. The best part is you DO NOT have to recruit or sell if you 
choose not to. Just being a member will avail you to unbelievable wealth
building tools and information formerly reserved only for the rich and famous. 
 If you want to test me on my claim to retire with this, financially, within
my first 6-9 months, do yourself a favor and click here
<mailto:glue143@hotmail.com?subject=More_Info_Please> for more info, and then
simply click on send, you do not need to add any info in the body... just two
clicks and I will respond with info you NEED to have.  Thanks for your time,
GLUE Glue143@hotmail.com <mailto:Glue143@hotmail.com> National Voice Mail
877.795.8921 
To be removed from my list of future mailings on this subject click here
<mailto:glue143@hotmail.com?subject=remove_please>. Thank-You. 

qbcwnltiyd

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

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

From: retsiemynnaht@spammoc.beoohaygon...               26-Nov-99 00:34:11
  To: All                                               26-Nov-99 10:42:21
Subj: Re: Compiler bugs in VAC++ 3.0 FP8

Message sender: retsiemynnaht@spammoc.beoohaygone.net

From: "Mike Ruskai" <retsiemynnaht@spammoc.beoohaygone.net>

On Thu, 25 Nov 1999 23:56:42 -0500 (EST), Mike Ruskai wrote:

>On Thu, 25 Nov 1999 22:40:03 GMT, Paul Ratcliffe wrote:
>
>>Hey, has anyone seen this bug before in VAC++ 3.0 with FP8. Try compiling it
>>using icc test.c and then icc /O test.c and running it:
[snip]

>>    for (i=1; i<14; i++)
>>        {
>>        lineBuff[i]=horzBar;
>>        }

Incidentally, I've replaced all these loops with memset() calls.  The above
would be this, instead:

memset(lineBuff+1, horzBar, 13);

The others follow the same pattern.  Faster than the loop, and not obscure,
either.  I originally used the loops because I was tired at the time, and
memset() didn't exist in my head - only memcpy(), which wouldn't work, hence
the loops.

Not that performance is a big issue with the program.  

If you're interested, you can grab the altered DisplayFunctions.c file here:

http://home.att.net/~thanny/dispfunc.zip


--
 - Mike

Remove 'spambegone.net' and reverse to send e-mail.


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

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

From: C.J.@btsoftware.com                               26-Nov-99 09:52:24
  To: All                                               26-Nov-99 10:42:22
Subj: HPP different download address !!!!!

From: "C.J." <C.J.@btsoftware.com>

HomePage Publisher
***************************

HomePage Publisher is an integrated WYSIWYG HTML publisher and
editor/browser. HPP enables you to create or modify any HTML pages. Easy to
use, it does not require knowledge of HTML tags. With HPP, you will be able
to modify pages and images directly in your document.

Check it out and download the free trial version:
http://www.btsoftware.com/os2/hpp.htm



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

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

From: josef.kores@telecom.at                            27-Nov-99 01:30:22
  To: All                                               26-Nov-99 21:40:22
Subj: Re: os2  Warp 4 Install problem

From: "josef.kores" <josef.kores@telecom.at>

Neil <n.crombie@unitronnedworks.nl> schrieb in im Newsbeitrag:
943371106.8777.0.pluto.d4ee0cab@news.demon.nl...
> Can anyone help my poor system administrator, he's trying to install os2
> warp4.The package consist of 4 cd's and 3 disks (dutch version) and at the
> end of the install it asks for the "Introduction disk" to be inserted in
> drive a.
> We have tried creating new install disks but it still asks for the
> "Introduction disk" after the first reboot in the installation. Are we
> missing a disk or is this a known bug?
> We tried IBM but they were usless...
>
>
> Neil & Manole
>
> bios-hdd-normal not lba while installing-after the first wright back
correct bios
>


--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: telecom.at (Vienna, Austria) (1:109/42)

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

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