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

                 Saturday, 11-Sep-1999 to Friday, 17-Sep-1999

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

From: mm2@phototiger.com                                10-Sep-99 23:59:24
  To: All                                               11-Sep-99 04:50:25
Subj: FP10 and Watcom 10.6 Debugger

From: "Michael Moegn" <mm2@phototiger.com>

Hello,
after installing FP10, my Watcom debugger (10.6) is not longer working.
When I start a program in the debugger, it only can be executed to the
WinCreateMsgQueue statement. Then the program will be stopped and the
debugger shows a "Task Completed" message in the debugger status line.

Michael

--
P h o t o T i g e r 2.01 Photoeditor for OS/2 Warp
Download: http://www.phototiger.com  Email: info@phototiger.com
*** Support Shareware, Support OS/2, Pay Your Shareware Fee ***


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

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

From: mamodeo@stny.rr.com                               10-Sep-99 18:24:26
  To: All                                               11-Sep-99 04:50:25
Subj: Re: FP10 and Watcom 10.6 Debugger

From: Marty <mamodeo@stny.rr.com>

Michael Moegn wrote:
> 
> Hello,
> after installing FP10, my Watcom debugger (10.6) is not longer working.
> When I start a program in the debugger, it only can be executed to the
> WinCreateMsgQueue statement. Then the program will be stopped and the
> debugger shows a "Task Completed" message in the debugger status line.

Same here.  The Watcom debugger has proven to be quite useless to me for PM
apps.  I submitted a bug report on this topic to Sybase back when Watcom
was still in production and was completely ignored.

Even without FP10 installed, the debugger frequently locked up my system
and did not handle multithreaded applications correctly.  My advice to you
is start using a lot of printfs for debugging.  ;-)

- Marty

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

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

From: nolospamoawmg@yesic.com                           10-Sep-99 22:30:18
  To: All                                               11-Sep-99 04:50:26
Subj: Object Desktop 2 - Hacking the LNF

From: "andrew g" <nolospamoawmg@yesic.com>

The Young Person's Guide to Hacking the LNF:

Everybody knows and it's documented in the Stardock
Look 'n Feel kit for OS/2 that you can create new
bitmap looks for your titlebars using VisualAge C++,
and I gave Kris Kwilas the makefile for CSET++ 2.1,
so even if you have an old compiler you can still
change your "look".

I may be the only OD2 user to have made an LNF, judging
by the apathy I see around me and on Stardock's part. I
didn't mind using the C Compiler, but I got tired of
waiting for the promised API to turn off those darned
lines on the title bars!

If you just want to change your titlebar bitmaps,
and don't want the annoying MacIntosh-like lines on 
your titlebars, you can use the ResMgr package available
from Hobbes, to gut the distributed Windows 95 LNF, and
remake it into something palatable. The Resource Manager
package contains a couple of utilities you will need to
do this, and along with the OS/2 resource compiler and
the icon editor, you're ready to roll your own title
bars.

Here's what I did:

copy your OBJDWN95.LNF from the \objdesk directory
to an empty \tmp directory. Rename OBJDWN95.LNF 
OBJDWN95.DLL, and use the resource decompiler to 
extract the bitmaps. Like this:

[c:\tmp]rdc OBJDWN95.DLL

There should be 66 buttons, and here they are, with
descriptions. If you want to distribute your LNF,
then you ought to alter all of them using OS/2
iconedit.exe. But if you know which ones your computer
uses, then just alter the ones you need for your
personal machine if you don't want to share your
customizations with others. For instance, on my
ThinkPad at 800x600, OS/2 uses only the 18x18
titlebar bitmaps, so they're the only ones I ever
change.

(note that there's no difference between the
hide and minimize bitmaps in the Windows 95
LNF as published).

 Size		 eas    filename	 purpose
---------------------------------------------
 290           0  res02514.bmp   18maximize_dn
 290           0  res02515.bmp   18restore__up
 290           0  res02789.bmp   18rollup___up
 218           0  res03064.bmp   scroll button
1322           0  res03339.bmp   22close____up
 194           0  res05864.bmp   scroll button
 290           0  res08939.bmp   18minimize_dn
 290           0  res09214.bmp   18close____up
 218           0  res09489.bmp   scroll button
1322           0  res09764.bmp   22minimize_up
 194           0  res12289.bmp   scroll button
 290           0  res15364.bmp   system menu
 170           0  res15639.bmp   scroll button
 290           0  res18714.bmp   18minimize_dn
 242           0  res19264.bmp   scroll button
 170           0  res22064.bmp   scroll button
 314           0  res22339.bmp   20hide_____up
 290           0  res25139.bmp   18minimize_up
 170           0  res28489.bmp   scroll button
 314           0  res28764.bmp   20maximize_up
1322           0  res29039.bmp   system menu
 290           0  res31839.bmp   18rollup___dn
 314           0  res35464.bmp   20rollup___dn
 290           0  res38264.bmp   18close____dn
 218           0  res38539.bmp   scroll button
1322           0  res38814.bmp   22minimize_dn
 194           0  res41339.bmp   scroll button
 314           0  res41889.bmp   20close____dn
 290           0  res44414.bmp   18minimize_up
 218           0  res44964.bmp   scroll button
1322           0  res45239.bmp   22restore__dn
 242           0  res48314.bmp   scroll button
 242           0  res48315.bmp   scroll button
 170           0  res51114.bmp   scroll button
 314           0  res51389.bmp   20minimize_up
1322           0  res51664.bmp   22maximize_dn
1322           0  res55014.bmp   22rollup___dn
 290           0  res57264.bmp   system menu
1322           0  res58089.bmp   22minimize_up
1322           0  res58090.bmp   22minimize_dn
 290           0  res60614.bmp   18restore__dn
 314           0  res60889.bmp   system menu
 242           0  res61164.bmp   scroll button
 218           0  res67589.bmp   scroll button
1322           0  res67864.bmp   22close____dn
 194           0  res70389.bmp   scroll button
 314           0  res70939.bmp   20rollup___up
 290           0  res73464.bmp   18maximize_up
 314           0  res77364.bmp   20close____up
 170           0  res80164.bmp   scroll button
 314           0  res80439.bmp   20hide_____dn
1322           0  res80714.bmp   22restore__up
 194           0  res83239.bmp   scroll button
 314           0  res86864.bmp   20hide_____dn
1322           0  res87139.bmp   22maximize_up
 314           0  res89939.bmp   20minimize_up
 242           0  res90214.bmp   scroll button
 242           0  res90215.bmp   scroll button
1322           0  res90489.bmp   22rollup___up
 170           0  res93014.bmp   scroll button
 314           0  res93289.bmp   20maximize_dn
 314           0  res96364.bmp   system menu
 218           0  res96639.bmp   scroll button
 194           0  res99439.bmp   scroll button
 314           0  res99714.bmp   20minimize_dn
1322           0  res99989.bmp   system menu
       66 file(s)      31908 bytes used

Now you edit the titlebar buttons you want to change,
saving them with the same filename they had before.

I use a batchfile to call iconedit.exe, like this:
REM -------------------------
REM ED.CMD
iconedit res02514.bmp
REM   18maximize_dn   
iconedit res02515.bmp
REM   18restore__up  
iconedit res02789.bmp
REM   18rollup___up  
iconedit res08939.bmp  
rem  18minimize_dn  
iconedit  res09214.bmp 
rem    18close____up  
iconedit  res18714.bmp 
rem    18minimize_dn  
iconedit  res25139.bmp 
rem    18minimize_up  
iconedit  res31839.bmp 
rem    18rollup___dn  
iconedit  res38264.bmp 
rem    18close____dn  
iconedit  res44414.bmp 
rem    18minimize_up  
iconedit  res60614.bmp 
rem    18restore__dn  
iconedit  res73464.bmp 
rem    18maximize_up  
REM --------------------------

After you've made the adjustments to the bitmaps,
and saved them all with their old names, you're
ready to use rc.exe to make your new LNF.

In the same \tmp directory, run RC.exe like this:

[c:\tmp]rc OBJDWN95.RC2 OBJDWN95.DLL

It will grind and mash all those nice bitmaps overtop
the ugly old Windows lookalikes.  Now you copy the
new OBJDWN95.DLL to your \objdesk directory, renaming
it to OBJDWN95.LNF.

[c:\tmp]copy OBJDWN95.DLL \objdesk\OBJDWN95.LNF

Open up your Master Setup in your Object Desktop folder,
and click the Window Controls tab.  Scroll down the list
of available LNF's to the one that says Windows 95.

Select it, and watch your new creation become the titlebar
icons on all your windows. You have successfully hacked
Object Desktop 2, and eradicated the cursed Look 'n Feel
of Windows 95. You are now a local hero.

Congratulations.








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

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

From: bwardell@mw.mediaone.net                          11-Sep-99 04:23:11
  To: All                                               11-Sep-99 04:50:26
Subj: Re: Object Desktop 2 - Hacking the LNF

From: "Brad Wardell" <bwardell@mw.mediaone.net>

Cool!  Thanks for posting that, Andrew.

Brad
--
Brad Wardell
Stardock - http://www.stardock.com

>


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

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

From: rlalla@stepnet.REMOVETHIS.de                      11-Sep-99 08:20:13
  To: All                                               11-Sep-99 04:50:27
Subj: Re: Object Desktop 2 - Hacking the LNF

From: "Robert Lalla" <rlalla@stepnet.REMOVETHIS.de>

On Fri, 10 Sep 1999 22:30:36 -0400 (EDT), andrew g wrote:

>I may be the only OD2 user to have made an LNF, judging
>by the apathy I see around me and on Stardock's part. I

Once when OD2-fp1 came out I installed it.
But then is was faced to frequent crashes of WPS.
So I reinstalled ODpro1.5.

--
RL




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

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

From: whonea@codenet.net                                11-Sep-99 01:39:06
  To: All                                               11-Sep-99 10:18:22
Subj: Re: FP10 and Watcom 10.6 Debugger

From: whonea@codenet.net (Will Honea)

On Fri, 10 Sep 1999 21:59:48, "Michael Moegn" <mm2@phototiger.com> 
wrote:

You might try backing up to the 10.0 or 10a debugger - that one works 
fine with FP11 here - DOS, OS/2, Win.

> Hello,
> after installing FP10, my Watcom debugger (10.6) is not longer working.
> When I start a program in the debugger, it only can be executed to the
> WinCreateMsgQueue statement. Then the program will be stopped and the
> debugger shows a "Task Completed" message in the debugger status line.
>  
> Michael

Will Honea <whonea@codenet.net>

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

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

From: arjen@removethis.hacom.nl                         11-Sep-99 15:04:01
  To: All                                               11-Sep-99 20:32:14
Subj: Re: Object Desktop 2 - Hacking the LNF

From: "Arjen Meijer" <arjen@removethis.hacom.nl>

On Sat, 11 Sep 1999 08:20:27 +0200 (MEZ), Robert Lalla wrote:

Most likely it are problems in the WPS, not OD. So upgrade to fixpack 11 and
try
again!

Arjen

:>On Fri, 10 Sep 1999 22:30:36 -0400 (EDT), andrew g wrote:
:>
:>>I may be the only OD2 user to have made an LNF, judging
:>>by the apathy I see around me and on Stardock's part. I
:>
:>Once when OD2-fp1 came out I installed it.
:>But then is was faced to frequent crashes of WPS.
:>So I reinstalled ODpro1.5.
:>
:>--
:>RL
:>
:>
:>
:>



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

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

From: dgraef@ibm.net                                    11-Sep-99 17:32:04
  To: All                                               11-Sep-99 20:32:14
Subj: WinDlgBox(); / WM_INITDLG

From: "Detlef Graef" <dgraef@ibm.net>

Hello,

I've a Dialog-Procedure witch is called like this:

        case IDM_FILE_SETTINGS:
               {

               WinDlgBox (HWND_DESKTOP,
                          hwnd,
                          NoteBookDlgProc,
                          NULLHANDLE,                  /* Resource in EXE */
                          IDD_SETTINGS_NOTEBOOK,       /* Dialog id */
                          NULL);                       /* No add'l data */
               }
               break;

Here the source of NoteBookDlgProc()  :

/****************************************************************************/
/* Custom window procedure for "Settings-Notebook" dialog.                  */
/****************************************************************************/

MRESULT EXPENTRY  NoteBookDlgProc(HWND hwnd, ULONG msg, MPARAM mp2, MPARAM
mp1)  /* DLG-Proc. fuer Settings-Notebook */
     {

    MRESULT mr = 0;      /* Result code */
    HWND hwndOK;         /* Window handle of OK push button */

   switch (msg)
       {
       case WM_INITDLG:
                  InitNoteBookDlg();    /* never executed */
      
          break;

       /* If the user hits OK, use WinDismissDlg to return TRUE to the main    
  */
       /* window procedure.  Otherwise, return FALSE.  This value is picked up 
  */
       /* as the return value of WinDlgBox.                                    
  */

      case WM_COMMAND:

        switch (SHORT1FROMMP (mp1))
           {
            case PB_UNDO:

               WinDismissDlg (hwnd,      /* Dialog Window Handle */
                              TRUE);     /* UNDO button is TRUE */
               return 0;

            case PB_DEFAULT:

               WinDismissDlg (hwnd,      /* Dialog Window Handle */
                              TRUE);     /* DEFAULT button is TRUE */
               return 0;

            case PB_HELP:

               WinDismissDlg (hwnd,      /* Dialog Window Handle */
                              TRUE);     /* HELP button is TRUE */
               return 0;

            default:
               mr = WinDefDlgProc(hwnd, msg, mp1, mp2);
               break;
           }
        break;

     /* Let the default dialog box window procedure handle any other messages  
*/
     /* for this dialog.                                                       
*/
     default:
        mr = WinDefDlgProc (hwnd, msg, mp1, mp2);   /* SYS3175 in PMMERGE.DLL  
*/
        break;
    }
 return (mr);
}

>------------------------------------------------------------------------------
--------------------

I've debugged the procedure. 
First       switch (msg)    is executed, and than immediatly WindefDlgProc();
with a crash
in PMMERGE.DLL

"mp1" has a value of 0 (zero), and "msg" a value of 83

Why the crash? I think the value of zero of mp1 is not correct.
Is it possible to find out which message is assigned to the value of 83?
(header-files)

Normally the WM_INITDLG-Msg. is send/posted to the Procedure before
WinDlgBox();
returns. Ist that correct? Why is the code at WM_INITDLG never executed.
In another Prg. the same code works fine.

I've found in PMWIN.H th definition of the messages:

   #define WM_CALCFRAMERECT           0x0053   /*   dec. 83 should be 0x0053
*/
Why is this message posted?
Due the definition in the RC-File?

With best regards,

D. Graef






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

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

From: mckinnis@ibm.net                                  11-Sep-99 10:13:03
  To: All                                               11-Sep-99 20:32:15
Subj: Re: Object Desktop 2 - Hacking the LNF

From: Chuck McKinnis <mckinnis@ibm.net>

If you are at FP11, you may get bitten by the HPFS change in FP11 that
caused directory entries to get the archive bit set on.  Visit
http://www.os2ss.com/users/mckinnis for a discussion and a workaround. 
I used to get WPS resets with OD2 Object Navigator on a fairly regular
basis until I backed off the HPFS updates.

Robert Lalla wrote:
> 
> On Fri, 10 Sep 1999 22:30:36 -0400 (EDT), andrew g wrote:
> 
> >I may be the only OD2 user to have made an LNF, judging
> >by the apathy I see around me and on Stardock's part. I
> 
> Once when OD2-fp1 came out I installed it.
> But then is was faced to frequent crashes of WPS.
> So I reinstalled ODpro1.5.
> 
> --
> RL

-- 
Chuck McKinnis
Senior Systems Engineer
Denver Solutions Group, Inc.
IBM Business Partner
IBM Senior Systems Engineer (retired)

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

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

From: lampsstgt@aol.com                                 11-Sep-99 16:41:17
  To: All                                               11-Sep-99 20:32:15
Subj: Netscape WWW_RegisterProtocol doesn't work

From: lampsstgt@aol.com (Lamps stgt)

i am using dde to implement navigation support in my application. i used the
topic 
WWW_RegisterProtocol (with protocol 'file'). 
After a filename was requested by netscape, i get a WM_DDE_INITIATE with topic
'WWW_OpenURL'. Then i send back WinDdeRespond(HwndNetscape, myHwnd,
myName,"WWW_OpenURL", &Context) and get a WM_DDE_TERMINATE (!). 
But how can i get the requested filename? I'm missing 
something like WM_DDE_REQUEST or WM_DDE_DATA. 

The same behaviour when i'm using topic WWW_RegisterURLEcho - i get a
WM_DDE_INITIATE with topic 'WWW_URLEcho' but no data containing the URL.

what's wrong? 
Thanks, Thomas

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: AOL Bertelsmann Online GmbH & Co. KG http://www.g
(1:109/42)

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

From: abuse@orac.clara.co.uk                            12-Sep-99 00:06:10
  To: All                                               12-Sep-99 04:17:18
Subj: Re: WinDlgBox(); / WM_INITDLG

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

On Sat, 11 Sep 1999 17:32:08 +0100 (MEZ), Detlef Graef <dgraef@ibm.net> wrote:

>MRESULT EXPENTRY  NoteBookDlgProc(HWND hwnd, ULONG msg, MPARAM mp2, MPARAM
mp1)  /* DLG-Proc. fuer Settings-Notebook */
>
>I've debugged the procedure. 
>First       switch (msg)    is executed, and than immediatly WindefDlgProc(); 
with a crash
>in PMMERGE.DLL
>
>"mp1" has a value of 0 (zero), and "msg" a value of 83
>
>Why the crash? I think the value of zero of mp1 is not correct.

You might get better results if you declared your function correctly :-)
mp1 and mp2 are the wrong way round, which is going to cause all sorts of
grief!

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

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

From: mamodeo@stny.rr.com                               11-Sep-99 20:45:25
  To: All                                               12-Sep-99 04:17:18
Subj: One for the EMX gurus...

From: Marty <mamodeo@stny.rr.com>

Below is the log of what should be a <really> simple process.  One .c file
calling one library function in one library.  I compile the .c files with
the -g switch because I'm trying to get a bigger application with debug
information so I can use GDB with it.  I create the archive file for the
"library" using ar.  When I try to link with ld (using the gcc frontend) it
tells me that any and all symbols defined in the library are undefined. 
When I use nm to list the contents of the library, the symbol shows up
exactly as specified in the error message.  What am I doing wrong?!?!

- Marty

epm: I:\gccdev\test >type test.c
#include <stdio.h>

extern void sayhello( void );

int main( void ) {
	printf( "Hello.\n" );
	sayhello();
	return 0;
}
epm: I:\gccdev\test >type test2.c
#include <stdio.h>

void sayhello( void ) {
	printf( "Hello there.\n" );
}
epm: I:\gccdev\test >gcc -g -c test.c

epm: I:\gccdev\test >gcc -g -c test2.c

epm: I:\gccdev\test >ar cr test2.a test2.o

epm: I:\gccdev\test >dir

The volume label in drive I is GCC DEV.
The Volume Serial Number is A736:9415.
Directory of I:\gccdev\test

 9-11-99   2:58p     <DIR>           0  .
 9-11-99   2:58p     <DIR>           0  ..
 9-11-99   8:13p       179          35  test.c
 9-11-99   8:22p      1813           0  test.o
 9-11-99   8:22p      1812           0  test2.a
 9-11-99   8:21p        79          35  test2.c
 9-11-99   8:22p      1657           0  test2.o
        7 file(s)       5540 bytes used
                   1482752 K bytes free

epm: I:\gccdev\test >gcc -g -Zexe -L. -ltest2 test.o
test.c:8 (test.o): Undefined symbol _sayhello referenced from text segment

epm: I:\gccdev\test >nm test2.a

test2.o:
00000000 t ___gnu_compiled_c
         U _printf
0000000e T _sayhello
00000000 t gcc2_compiled.

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

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

From: ian_harvey@do.not.spam.me                         10-Sep-99 18:58:11
  To: All                                               12-Sep-99 04:17:18
Subj: Re: Combo boxes and bitmaps

From: Ian Harvey <ian_harvey@do.not.spam.me>

The file selection control is a container.  The combo-box like drive
selection control appears to be a custom control.

Paul Ratcliffe wrote:
> 
> On 9 Sep 1999 15:07:40 GMT, Glen D <glen@rockyhorror.Zkaroo.co.uk> wrote:
> 
> >I'm trying to do exactly what PMView has done and have a file dialog
> >box with little icons next to each drive item in the combo-box.  It's
> 
> PMView uses an ordinary Container control to do this. There is no magic to
it
> as far as I'm aware.

-- 
IanH
Comments and questions welcome at ian_harvey at bigpond dot com
However, do _not_ send me unsolicited commercial email.

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

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

From: ian_harvey@do.not.spam.me                         11-Sep-99 07:25:19
  To: All                                               12-Sep-99 04:17:18
Subj: Re: IPF - panels defined by name

From: Ian Harvey <ian_harvey@do.not.spam.me>

IPF limitation - for *.hlp files or *.inf files that may be
concantenated you can only define a panel by number (must use the res
attribute for heading tags etc.).

Or are you asking why IPF has that limitation ?  (Maybe because it is
easier to identify a help panel within application code by a numeric ID
??)

peroy@my-deja.com wrote:
> 
> Sorry for my so poor english...
> I'm trying to convert into IPF a Help file coming
> from Wysihelp. Wysihelp generates a RTF file,
> RTF2IPF tranlates it into an IPF file, and IPFC
> gives me a HLP file for OS/2 (correctly
> generated).
> My problem is the following : why are all the
> panels only "defined by number" and none "defined
> by name"?
> 
> Sent via Deja.com http://www.deja.com/
> Share what you know. Learn what you don't.

-- 
IanH
Comments and questions welcome at ian_harvey at bigpond dot com
However, do _not_ send me unsolicited commercial email.

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

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

From: jmartin@csr.uvic.ca                               12-Sep-99 03:10:01
  To: All                                               12-Sep-99 05:23:09
Subj: Re: One for the EMX gurus...

From: Johannes Martin <jmartin@csr.uvic.ca>

Marty <mamodeo@stny.rr.com> wrote:
: Below is the log of what should be a <really> simple process.  One .c file
: calling one library function in one library.  I compile the .c files with
: the -g switch because I'm trying to get a bigger application with debug
: information so I can use GDB with it.  I create the archive file for the
: "library" using ar.  When I try to link with ld (using the gcc frontend) it
: tells me that any and all symbols defined in the library are undefined. 
: When I use nm to list the contents of the library, the symbol shows up
: exactly as specified in the error message.  What am I doing wrong?!?!
Run:
	ar s test.a 
after creating your libary with 'ar cr ...'.
'ar s' is the equivalent to 'ranlib' - it generates the index for your
archive.

Johannes

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

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

From: mamodeo@stny.rr.com                               12-Sep-99 00:38:03
  To: All                                               12-Sep-99 05:23:09
Subj: Re: One for the EMX gurus...

From: Marty <mamodeo@stny.rr.com>

Johannes Martin wrote:
> 
> Marty <mamodeo@stny.rr.com> wrote:
> : Below is the log of what should be a <really> simple process.  One .c file
> : calling one library function in one library.  I compile the .c files with
> : the -g switch because I'm trying to get a bigger application with debug
> : information so I can use GDB with it.  I create the archive file for the
> : "library" using ar.  When I try to link with ld (using the gcc frontend)
it
> : tells me that any and all symbols defined in the library are undefined.
> : When I use nm to list the contents of the library, the symbol shows up
> : exactly as specified in the error message.  What am I doing wrong?!?!
> Run:
>         ar s test.a
> after creating your libary with 'ar cr ...'.
> 'ar s' is the equivalent to 'ranlib' - it generates the index for your
> archive.

Didn't work.  :-(

[I:\gccdev\test]ar s test2.a

[I:\gccdev\test]gcc -g -L. -ltest2 test.o
test.c:8 (test.o): Undefined symbol _sayhello referenced from text segment

- Marty

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

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

From: ilya@math.ohio-state.edu                          12-Sep-99 07:53:27
  To: All                                               12-Sep-99 10:18:25
Subj: Re: One for the EMX gurus...

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

[A complimentary Cc of this posting was sent to Marty 
<mamodeo@stny.rr.com>],
who wrote in article <37DAF7BF.3CC1F360@stny.rr.com>:
> epm: I:\gccdev\test >gcc -g -Zexe -L. -ltest2 test.o
> test.c:8 (test.o): Undefined symbol _sayhello referenced from text segment

But of course!  When test.o is linked, there is an unresolved symbol
sayhello().  There is no library to get it from.

Try 

 gcc -g -Zexe -o test test.o -L. -ltest2 

Ilya

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

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

From: mamodeo@stny.rr.com                               12-Sep-99 04:05:02
  To: All                                               12-Sep-99 10:18:25
Subj: Re: One for the EMX gurus...

From: Marty <mamodeo@stny.rr.com>

Ilya Zakharevich wrote:
> 
> [A complimentary Cc of this posting was sent to Marty
> <mamodeo@stny.rr.com>],
> who wrote in article <37DAF7BF.3CC1F360@stny.rr.com>:
> > epm: I:\gccdev\test >gcc -g -Zexe -L. -ltest2 test.o
> > test.c:8 (test.o): Undefined symbol _sayhello referenced from text segment
> 
> But of course!  When test.o is linked, there is an unresolved symbol
> sayhello().  There is no library to get it from.
> 
> Try
> 
>  gcc -g -Zexe -o test test.o -L. -ltest2

Bah!  Order of parameters counts?!  <smacks head>

Thanks Ilya.  I owe ya one!

- Marty

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

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

From: mamodeo@stny.rr.com                               12-Sep-99 04:24:11
  To: All                                               12-Sep-99 10:18:25
Subj: Re: One for the EMX gurus...

From: Marty <mamodeo@stny.rr.com>

Marty wrote:
> 
> Ilya Zakharevich wrote:
> >
> > [A complimentary Cc of this posting was sent to Marty
> > <mamodeo@stny.rr.com>],
> > who wrote in article <37DAF7BF.3CC1F360@stny.rr.com>:
> > > epm: I:\gccdev\test >gcc -g -Zexe -L. -ltest2 test.o
> > > test.c:8 (test.o): Undefined symbol _sayhello referenced from text
segment
> >
> > But of course!  When test.o is linked, there is an unresolved symbol
> > sayhello().  There is no library to get it from.
> >
> > Try
> >
> >  gcc -g -Zexe -o test test.o -L. -ltest2
> 
> Bah!  Order of parameters counts?!  <smacks head>
> 
> Thanks Ilya.  I owe ya one!

Nuts... now I'm in real trouble...

LD looks like it's happy and doesn't spit out any error messages but it
crashes.  :-(

09-12-1999  04:18:04  SYS3171  PID 00ac  TID 0001  Slot 0080
I:\EMX\BIN\LD.EXE
c0000005
00015f49
P1=00000002  P2=0002e1b4  P3=XXXXXXXX  P4=XXXXXXXX  
EAX=00000000  EBX=003025a0  ECX=00000004  EDX=00000000
ESI=003025a0  EDI=000af5dc  
DS=0053  DSACC=d0f3  DSLIM=1fffffff  
ES=0053  ESACC=d0f3  ESLIM=1fffffff  
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:00015f49  CSACC=d0df  CSLIM=1fffffff
SS:ESP=0053:0002e1b8  SSACC=d0f3  SSLIM=1fffffff
EBP=0008af44  FLG=00012297

LD.EXE 0001:00005f49

This happens on the LD from EMX .9d FP2 I believe.
 5-06-99   9:43p     36278           0  ld.exe

It probably happens on others as well.  I think I'm overrunning something. 
The total size of everything it's trying to link together comes to about
41MB with all the debug info enabled.  Is there any option I can pass to
the linker to make it happier?

- Marty

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

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

From: mamodeo@stny.rr.com                               12-Sep-99 04:48:10
  To: All                                               12-Sep-99 10:18:25
Subj: Re: One for the EMX gurus...

From: Marty <mamodeo@stny.rr.com>

Marty wrote:
> 
> Marty wrote:
> >
> > Ilya Zakharevich wrote:
> > >
> > > [A complimentary Cc of this posting was sent to Marty
> > > <mamodeo@stny.rr.com>],
> > > who wrote in article <37DAF7BF.3CC1F360@stny.rr.com>:
> > > > epm: I:\gccdev\test >gcc -g -Zexe -L. -ltest2 test.o
> > > > test.c:8 (test.o): Undefined symbol _sayhello referenced from text
segment
> > >
> > > But of course!  When test.o is linked, there is an unresolved symbol
> > > sayhello().  There is no library to get it from.
> > >
> > > Try
> > >
> > >  gcc -g -Zexe -o test test.o -L. -ltest2
> >
> > Bah!  Order of parameters counts?!  <smacks head>
> >
> > Thanks Ilya.  I owe ya one!
> 
> Nuts... now I'm in real trouble...
> 
> LD looks like it's happy and doesn't spit out any error messages but it
> crashes.  :-(

Disregard that.  It was a stack space exception.  I bumped up the stack
space to 4MB and it was more than happy to produce my 31MB executable. 
How's that for bloat?  ;-)

Thanks for the help from those that replied.

- Marty

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

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

From: haraldei@bugoff.c2i.net                           12-Sep-99 09:39:22
  To: All                                               12-Sep-99 10:18:25
Subj: Re: KC_KEYUP problem

From: haraldei@bugoff.c2i.net (Harald Eilertsen)

On Wed, 8 Sep 1999 07:08:53, Sean Myers <sean.myers@qr.com.au> wrote:

> I am writing a small PM app, and I have noticed that I am not receiving
> any KC_KEYUP messages.  Is there something I have to do to make OS/2 send 
> me these messages?

No, but here's something I figured out when experimenting with this:

// Only process messages with valid scancode fields.
//
// Really we only care about the character code, but it seems that PM 
will never send
// a message with both the KC_CHAR & KC_KEYUP flags set. It will 
however send a message
// with KC_SCANCODE & KC_KEYUP set at once. This indicates the uschar 
field in the message
// is not valid. However looking more closely on this message it seems
that the least
// significant byte of the uschar field contains the valid character 
code, while the
// most significant byte holds the scancode. We mask out the scancode,
and is left with the
// valid charcode, that enables us to turn off the right note.

Don't know if the assumption that the char code allways will be the 
lower byte in the uschar field will be valid in all NLS versions. But 
for single byte character sets I think it should be fairly safe.

Take Care!
-- 
Harald Eilertsen (haraldei@bugoff.c2i.net)
Posted by ProNews/2 on OS/2
(Spammers bug off!)

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Tele2 Norway AS Public Access (1:109/42)

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

From: kenames@earthlink.net                             12-Sep-99 18:02:02
  To: All                                               12-Sep-99 20:02:00
Subj: Re: One for the EMX gurus...

From: kenames@earthlink.net

damn Marty, thats a big one! are you trying to emulate windows?

 Ken

On Sun, 12 Sep 1999 08:48:20, Marty <mamodeo@stny.rr.com> wrote:

> Marty wrote:
> > 
> > Marty wrote:
> > >
> > > Ilya Zakharevich wrote:
> > > >
> > > > [A complimentary Cc of this posting was sent to Marty
> > > > <mamodeo@stny.rr.com>],
> > > > who wrote in article <37DAF7BF.3CC1F360@stny.rr.com>:
> > > > > epm: I:\gccdev\test >gcc -g -Zexe -L. -ltest2 test.o
> > > > > test.c:8 (test.o): Undefined symbol _sayhello referenced from text
segment
> > > >
> > > > But of course!  When test.o is linked, there is an unresolved symbol
> > > > sayhello().  There is no library to get it from.
> > > >
> > > > Try
> > > >
> > > >  gcc -g -Zexe -o test test.o -L. -ltest2
> > >
> > > Bah!  Order of parameters counts?!  <smacks head>
> > >
> > > Thanks Ilya.  I owe ya one!
> > 
> > Nuts... now I'm in real trouble...
> > 
> > LD looks like it's happy and doesn't spit out any error messages but it
> > crashes.  :-(
> 
> Disregard that.  It was a stack space exception.  I bumped up the stack
> space to 4MB and it was more than happy to produce my 31MB executable. 
> How's that for bloat?  ;-)
> 
> Thanks for the help from those that replied.
> 
> - Marty



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

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

From: csaba.raduly@sophos.com                           12-Sep-99 19:55:14
  To: All                                               12-Sep-99 20:02:00
Subj: Re: FP10 and Watcom 10.6 Debugger

From: Csaba Raduly <csaba.raduly@sophos.com>

Marty wrote:
> 
> Michael Moegn wrote:
> >
> > Hello,
> > after installing FP10, my Watcom debugger (10.6) is not longer working.
> > When I start a program in the debugger, it only can be executed to the
> > WinCreateMsgQueue statement. Then the program will be stopped and the
> > debugger shows a "Task Completed" message in the debugger status line.
> 
> Same here.  The Watcom debugger has proven to be quite useless to me for PM

Even though WDW has loads of bugs, this is not its fault.
* ALL * debuggers ( IPMD & ICSDEBUG from IBM; (pm)gdb from emx ) 
would behave the same. You need to go back to around FP6-level
pmmerge.dll
to fix this. I had this problem and the fix worked.

Are you listening, IBM ? Perhaps it's not too late to fix this in FP12 ?

Csaba
-- 
-----BEGIN GEEK CODE BLOCK----- 
Version 3.1
GCS/>GMU 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: mamodeo@stny.rr.com                               12-Sep-99 15:32:06
  To: All                                               12-Sep-99 20:02:00
Subj: Re: One for the EMX gurus...

From: Marty <mamodeo@stny.rr.com>

kenames@earthlink.net wrote:
> 
> damn Marty, thats a big one! are you trying to emulate windows?

Heh.. not yet.  ;-)

MAME has quite a few symbols defined.  Stripping out the symbolic info, the
executable is a paltry 8MB.  ;-)

Now all I have to do is figure out how to use this PMGDB.  It keeps
complaining about being started in a VIO window and that it could lock my
system if I use it to debug a PM app.  At least it lets me examine core
files and do post-mortems on it, which is an enormous help by itself.

- Marty

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

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

From: ilya@math.ohio-state.edu                          12-Sep-99 22:24:28
  To: All                                               13-Sep-99 03:45:01
Subj: Re: One for the EMX gurus...

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

[A complimentary Cc of this posting was sent to Marty 
<mamodeo@stny.rr.com>],
who wrote in article <37DBFFBC.103FF5D7@stny.rr.com>:
> kenames@earthlink.net wrote:
> > 
> > damn Marty, thats a big one! are you trying to emulate windows?
> 
> Heh.. not yet.  ;-)
> 
> MAME has quite a few symbols defined.  Stripping out the symbolic info, the
> executable is a paltry 8MB.  ;-)
> 
> Now all I have to do is figure out how to use this PMGDB.  It keeps
> complaining about being started in a VIO window and that it could lock my
> system if I use it to debug a PM app.  At least it lets me examine core
> files and do post-mortems on it, which is an enormous help by itself.

What I do (with -Zomf executables) is to start sd386 in a full-screen
session and debug from there.  I think gdb allows the same.

Ilya

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

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

From: thannymeister@spambegone.yahoo.com                12-Sep-99 20:10:21
  To: All                                               13-Sep-99 03:45:01
Subj: Re: One for the EMX gurus...

From: "Mike Ruskai" <thannymeister@spambegone.yahoo.com>

On Sun, 12 Sep 1999 15:32:12 -0400, Marty wrote:

>kenames@earthlink.net wrote:
>> 
>> damn Marty, thats a big one! are you trying to emulate windows?
>
>Heh.. not yet.  ;-)
>
>MAME has quite a few symbols defined.  Stripping out the symbolic info, the
>executable is a paltry 8MB.  ;-)
>
>Now all I have to do is figure out how to use this PMGDB.  It keeps
>complaining about being started in a VIO window and that it could lock my
>system if I use it to debug a PM app.  At least it lets me examine core
>files and do post-mortems on it, which is an enormous help by itself.

When you gave me the source a while back, for verion .31.4, VACPP 3.08
produced a 1.4MB executable when debug info was excluded.  Has it bulked up
that much since then?  Are you perhaps not compressing the executable?


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: mamodeo@stny.rr.com                               12-Sep-99 22:51:26
  To: All                                               13-Sep-99 05:47:24
Subj: Re: One for the EMX gurus...

From: Marty <mamodeo@stny.rr.com>

Mike Ruskai wrote:
> 
> On Sun, 12 Sep 1999 15:32:12 -0400, Marty wrote:
> 
> >kenames@earthlink.net wrote:
> >>
> >> damn Marty, thats a big one! are you trying to emulate windows?
> >
> >Heh.. not yet.  ;-)
> >
> >MAME has quite a few symbols defined.  Stripping out the symbolic info, the
> >executable is a paltry 8MB.  ;-)
> >
> >Now all I have to do is figure out how to use this PMGDB.  It keeps
> >complaining about being started in a VIO window and that it could lock my
> >system if I use it to debug a PM app.  At least it lets me examine core
> >files and do post-mortems on it, which is an enormous help by itself.
> 
> When you gave me the source a while back, for verion .31.4, VACPP 3.08
> produced a 1.4MB executable when debug info was excluded.  Has it bulked up
> that much since then?  Are you perhaps not compressing the executable?

No, it's been beefed up quite a bit since then.  I think .31 only supported
around 500 games compared to the current 1600 or so.  Also, some of the
PGCC optimizations make the exe quite a bit larger, but a bit faster too.

- Marty

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

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

From: hka@norman.no                                     13-Sep-99 08:31:13
  To: All                                               13-Sep-99 05:47:24
Subj: Q: Problem reading from partitions > 4GB

From: "Hans K. Aspenberg" <hka@norman.no>

Hi all,

The enclosed code tries to open all drives logically, from "A:" to "Z:" and
read the first sector off each drive. It works like a charm for all types of
disks, except for hard disk partitions > 4GB where DosRead() returns rc=5
ERROR_ACCESS_DENIED. (By the way, it works for > 4GB partitions when the
physical disk contains only one partition). Adding locking/unlocking code
around the read doesn't make any significance. I have studied all available
docs without becoming any wiser..

;-)) Hans

--- Code snippet ----

#include <stdio.h>             // Include std "C" header files.
#include <stdlib.h>

#define INCL_DOSDEVIOCTL
#define INCL_DOSDEVICES
#define INCL_DOSFILEMGR
#define INCL_DOSMISC
#define INCL_ERRORS
#define INCL_DOSSEMAPHORES
#define INCL_DOSMODULEMGR
#define INCL_DOSPROCESS
#ifndef __IBMC__
   #define __IBMC__ 0    // Define these to use Warp Toolkit headers from
Watcom.
   #define __IBMCPP__ 0
#endif
#include <os2.h>

VOID main (VOID)
{
   APIRET arRc = NO_ERROR;
   HFILE hDisk;
   CHAR cDrive;
   CHAR ucBuf [512];

   for (cDrive = 'A'; cDrive <= 'Z'; cDrive++) {
      printf ("\nDrive %c:", cDrive);
      arRc = _OpenLogDisk (cDrive - 'A', &hDisk);
      if (arRc == NRC_OK) {
         arRc = _ReadLogDisk (hDisk, 0, ucBuf);
         if (arRc == NRC_OK) {
            printf (" read OK.");
         }
         else {
            printf (" Read returned 0x%08X", arRc);
         }
         DosClose (hFile);
      }
      else {
         printf (" Open() returned 0x%08X", arRc);
      }
   }
}

APIRET _OpenLogDisk (NUSHORT usLogDisk,
                     PHFILE  phLogDisk)
{
   ULONG ulAct;
   APIRET arRc;
   CHAR  szDrive[3] = "A:";

   szDrive[0] = (CHAR) usLogDisk + 'A'; // Complete the drive name.
   arRc = DosOpen (szDrive, (PHFILE)phLogDisk,
                   &ulAct, 0L, 0L,
                   OPEN_ACTION_OPEN_IF_EXISTS,
                   OPEN_FLAGS_DASD| OPEN_FLAGS_FAIL_ON_ERROR|
OPEN_SHARE_DENYNONE,
                   (PEAOP2)NULL);
   return arRc;
}

#define SZE_SECTOR 0x200

APIRET _ReadLogDisk (HFILE hLogDisk,
                     ULONG ulSector,
                     PBYTE pbyBuffer)
{
   APIRET arRc;
   ULONG ulDummy;

   arRc = DosSetFilePtr ((HFILE)hLogDisk, (LONG)(ulSector * SZE_SECTOR),
                         FILE_BEGIN, &ulDummy);
   if (arRc == NO_ERROR) {
      arRc = DosRead ((HFILE)hLogDisk, pbyBuffer, SZE_SECTOR, &ulDummy);
   }
   return arRc;
}


---

Hans K. Aspenberg
hka@norman.no


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

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

From: m.karsch@ath.nl                                   13-Sep-99 10:38:16
  To: All                                               13-Sep-99 10:36:28
Subj: Re: FP10 and Watcom 10.6 Debugger

From: Michiel Karsch <m.karsch@ath.nl>

Same problem with Borlandc++ for OS/2 and FP11. Where can i get a working
pmmerge.dll, i program in the debugger.

Csaba Raduly wrote:

> Marty wrote:
> >
> > Michael Moegn wrote:
> > >
> > > Hello,
> > > after installing FP10, my Watcom debugger (10.6) is not longer working.
> > > When I start a program in the debugger, it only can be executed to the
> > > WinCreateMsgQueue statement. Then the program will be stopped and the
> > > debugger shows a "Task Completed" message in the debugger status line.
> >
> > Same here.  The Watcom debugger has proven to be quite useless to me for
PM
>
> Even though WDW has loads of bugs, this is not its fault.
> * ALL * debuggers ( IPMD & ICSDEBUG from IBM; (pm)gdb from emx )
> would behave the same. You need to go back to around FP6-level
> pmmerge.dll
> to fix this. I had this problem and the fix worked.
>
> Are you listening, IBM ? Perhaps it's not too late to fix this in FP12 ?
>
> Csaba
> --
> -----BEGIN GEEK CODE BLOCK-----
> Version 3.1
> GCS/>GMU 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: WorldOnline News server (1:109/42)

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

From: pfitzsim@home.com                                 13-Sep-99 09:27:03
  To: All                                               13-Sep-99 10:36:28
Subj: Re: Q: Problem reading from partitions > 4GB

From: Peter Fitzsimmons <pfitzsim@home.com>

Do a dejanews.com "past" search for 0xDEADFACE

It'll put the volume in "sector" mode, instead of "byte" mode.

-- 
Peter Fitzsimmons,      Toronto Canada.
email:pfitz@ican.net    Voice: 905-858-3222

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

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

From: csaba.raduly@sophos.com                           13-Sep-99 10:19:22
  To: All                                               13-Sep-99 10:36:28
Subj: Re: FP10 and Watcom 10.6 Debugger

From: Csaba Raduly <csaba.raduly@sophos.com>

Michiel Karsch wrote:
> 
> Same problem with Borlandc++ for OS/2 and FP11. Where can i get a working
> pmmerge.dll, i program in the debugger.
> 

FP6 is included in the June 1998 DevCon. I discovered this after
a kind member of the WarpUK mailing list has sent it to me :-)
I can mail it to you if you want.

Csaba
-- 
-----BEGIN GEEK CODE BLOCK----- 
Version 3.1
GCS/>GMU 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: isaacl@bulls.ece.ubc.ca                           13-Sep-99 19:19:09
  To: All                                               13-Sep-99 16:50:03
Subj: Re: Object Desktop 2 - Hacking the LNF

From: isaacl@bulls.ece.ubc.ca (e-frog)

Robert Lalla (rlalla@stepnet.REMOVETHIS.de) wrote:
: On Fri, 10 Sep 1999 22:30:36 -0400 (EDT), andrew g wrote:

: >I may be the only OD2 user to have made an LNF, judging
: >by the apathy I see around me and on Stardock's part. I

: Once when OD2-fp1 came out I installed it.
: But then is was faced to frequent crashes of WPS.
: So I reinstalled ODpro1.5.

What about the fact that the sample LNF was made for VAC++ only? It's a
rather expensive product (at least by my budgets).

Some of us can code a little bit and especially with a nice example to
follow, but rely on the IDE to do the makefiles.
I bet if somebody could get the LNF kit working with gcc (and nice
instructions), you'd get a few more submissions.



Isaac

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: ITServices, University of British Columbia (1:109/42)

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

From: whonea@codenet.net                                13-Sep-99 19:29:22
  To: All                                               14-Sep-99 18:43:05
Subj: Re: FP10 and Watcom 10.6 Debugger

From: whonea@codenet.net (Will Honea)

On Sun, 12 Sep 1999 18:55:28, Csaba Raduly <csaba.raduly@sophos.com> 
wrote:

> Even though WDW has loads of bugs, this is not its fault.
> * ALL * debuggers ( IPMD & ICSDEBUG from IBM; (pm)gdb from emx ) 
> would behave the same. You need to go back to around FP6-level
> pmmerge.dll
> to fix this. I had this problem and the fix worked.
>  
> Are you listening, IBM ? Perhaps it's not too late to fix this in FP12 ?
>
 
Whoops, something is fishy here!  I use ICSDEBUG on a daily basis with
Warp 4, fp11 - and there are 6 of us in the group using as many 
machines on the current app.  I used WDW for the last 2 weeks (version
10a and 10.6 both) to debug both an old DOS app I maintain as well as 
some OS/2 apps I wrote to test a port of that old code.  All 3 worked 
without a burp - the only problem I had was getting the right paths 
set up for the DOS VDM to debug that but that happens every time I 
fire it up again after a long layoff.  I won't speak for IPMD under fp
11, but I had it up under fp10 about a month ago checking an older 
version of  current app and it also ran fine. ICSDEBUG is at the FP8 
level.

I've seen a few posts about NT and AIX using VACPP 3.65 and VACPP 4 
debuggers on news.software.ibm.com but I don't recall see ANY using 
icsdebug from 3.0 under OS/2.

That said, there are some general video problems with certain video 
cards and drivers ( particularly the GRADD drivers and some Matrox 
cards) and the whole VACPP IDE - black icons, etc. - but this is the 
first complaint I've seen about the IBM debuggers not working.  I even
have Thesues/2 working with FP11, or at least not crashing it.

Will Honea <whonea@codenet.net>

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

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

From: hka@norman.no                                     14-Sep-99 11:38:20
  To: All                                               14-Sep-99 18:43:05
Subj: Re: Q: Problem reading from partitions > 4GB

From: "Hans K. Aspenberg" <hka@norman.no>

On Mon, 13 Sep 1999 09:27:07 GMT, Peter Fitzsimmons wrote:

:>Do a dejanews.com "past" search for 0xDEADFACE
:>
:>It'll put the volume in "sector" mode, instead of "byte" mode.

Tnx Peter. When pointed to it, I remembered vaguely something about this :-)
It is documented in the OS2UNDOC.INF that can be found on Hobbes. If someone
is interrested, I have enclosed a code snipped below that does the work:

;-)) Hans

---- Code snippet ----

/*------ _ S e t B l o c k M o d e ------------------------------------------

  Function  : Use undocumented HPFS FSD function to set handle in block mode.

  Parameters: Handle to logical disk.
  Returns   : API return code, preferrably NO_ERROR.
  Written by: Hans K. Aspenberg
  Revision  : 14-Sep-1999 1.00 /HKA/ Created.
  record

*/
static APIRET _SetBlockMode (HFILE hDisk)
{
   UCHAR   uchDataArea[16] = {0};           /* Input and output data area */
   ULONG   ulDataLen        = 0;            /* Input and output data size */
   ULONG   ulParm           = 0xDEADFACE;   /* Input and output for function
*/
   ULONG   ulParmLen        = 4;            /* Input and output parameter
size */
   ULONG   ulFunction       = 0x9014;       /* Device-specific function */
   APIRET  rc               = NO_ERROR;     /* Return code */

   rc = DosFSCtl(uchDataArea,         /* Input/output data area */
                 sizeof(uchDataArea), /* Maximum output data size */
                 &ulDataLen,          /* Input:  size of input data area */
                                      /* Output: size of data returned   */
                 &ulParm,             /* Input/Output parameter list */
                 4,                   /* Maximum output parameter size */
                 &ulParmLen,          /* Input:  size of parameter list */
                                      /* Output: size of parameters returned
*/
                 ulFunction,          /* Function being requested */
                 NULL,                /* File System Driver (FSD) name */
                 hDisk,               /* Handle for file */
                 FSCTL_HANDLE);       /* Indicate handle is the route */
   return rc;
}

---- End code snippet ----
---

Hans K. Aspenberg
hka@norman.no


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

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

From: Paulo.Santos@rnl.ist.utl.pt                       14-Sep-99 12:43:00
  To: All                                               14-Sep-99 18:43:05
Subj: Using Visibroker for Java in OS/2

From: "Paulo Santos" <Paulo.Santos@rnl.ist.utl.pt>

I can't initialize a visibroker ORB client in OS/2 with the Java 1.1.8
recently installed. My applet works in Windows NT, LINUX, UNIX but it
doesn't work on OS/2 when I run with appletviewer.
The problem seems to be in the static initializerof the orb: orb
org.omg.CORBA.ORB.init(applet,NULL).
I have the following parameter in the applet:
 <param  name=org.omg.CORBA.ORBClass value=com.visigenic.vbroker.orb.ORB>

This is the exception I get:

# Applet exception: java.lang.ExceptionInInitializerError
java.lang.ExceptionInInitializerError
 at java.lang.Throwable.<init>(Throwable.java:63)
 at java.lang.Error.<init>(Error.java:36)
 at java.lang.LinkageError.<init>(LinkageError.java:28)
 at
java.lang.ExceptionInInitializerError.<init>(ExceptionInInitializerError.jav
a:39)
 at java.lang.ClassLoader.resolveClass(ClassLoader.java:273)
 at netscape.applet.AppletClassLoader.loadClass1(AppletClassLoader.java:778)
 at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java:720)
 at netscape.applet.AppletClassLoader.loadClass(AppletClassLoader.java:697)
 at org.omg.CORBA.ORB.create_impl(ORB.java:295)
 at org.omg.CORBA.ORB.init(ORB.java:368)
 at com.easyphone.tfc80.jttalk.JTTalk.run(JTTalk.java:73)
 at java.lang.Thread.run(Thread.java:503)

and this is the exception that caused this ExceptionInInitializerError:

java.lang.ArithmeticException: / by zero
        at com.visigenic.vbroker.orb.ORB.extractTagFromStamp(Compiled Code)
        at
        at java.lang.ClassLoader.resolveClass(ClassLoader.java:230)
        at
sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:217)
        at
sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:177)
        at org.omg.CORBA.ORB.create_impl(ORB.java:295)
        at org.omg.CORBA.ORB.init(ORB.java:368)
        at com.easyphone.tfc80.jttalk.JTTalk.run(JTTalk.java:78)
        at java.lang.Thread.run(Thread.java:498)

Can you help me?
Thanks.

Paulo Santos




--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Universidade Tecnica de Lisboa (1:109/42)

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

From: KendallB@scitechsoft.com                          14-Sep-99 08:29:22
  To: All                                               14-Sep-99 18:43:06
Subj: OS/2 developer position at SciTech!

From: KendallB@scitechsoft.com (Kendall Bennett)

Hi All,

SciTech is currently looking to fill a fulltime OS/2 developer position 
within the company. The responsibilities of the position would include 
development of SciTech Display Doctor for OS/2, wxWindows for OS/2 (a 
core component of the SDD 7.0 user interface) and SciTech MGL for OS/2. 
The position will require relocation to our offices in Chico, California 
(about 1.5 hours north of Sacramento).

If you are interested in this position, please mail/fax your resume to my 
attention at:

 Kendall Bennett
 505 Wall Street
 Chico, CA 95928
 Fax: (530) 894 9069

If you wish to email me resumes, make sure they are either word documents 
or acrobat files so that I can print them and add them to our files. I 
won't accept text file resumes.

If you are not interested in this position, please pass this message onto 
friends who may be interested in applying.

Regards,

-- 

+----------------------------------------------------------------------+
|      SciTech Software - Building Truly Plug'n'Play Software!         |
+----------------------------------------------------------------------+
| Kendall Bennett          | To reply via email, remove nospam from    |
| Director of Engineering  | the reply to email address. Do NOT send   |
| SciTech Software, Inc.   | unsolicited commercial email!             |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com                |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com         |
+----------------------------------------------------------------------+

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

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

From: mek@compuserve.com                                14-Sep-99 11:21:13
  To: peroy@my-deja.com                                 14-Sep-99 18:43:06
Subj: Re: IPF - panels defined by name

To: peroy@my-deja.com
From: Mat Kramer <mek@compuserve.com>

In IPF, you can give a help panel both a resource number and/or a
name/ID.  If you want to link from an app, you need the resource number,
but it is possible to use both.  That is, you can use name for linking
internally, and IDs for linking from code.

You may also want to try VyperHelp to convert the HPJ/RTF to IPF.  It
preserves both names and numbers when translating.  See link below.

peroy@my-deja.com wrote:
> 
> I'm trying to convert into IPF a Help file coming
> from Wysihelp. Wysihelp generates a RTF file,
> RTF2IPF tranlates it into an IPF file, and IPFC
> gives me a HLP file for OS/2 (correctly
> generated).
> My problem is the following : why are all the
> panels only "defined by number" and none "defined
> by name"?

-- 
Mat Kramer [MekTek] mek@compuserve.com
VyperHelp: http://ourworld.compuserve.com/homepages/mek/vyper.htm

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

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

From: hubert@ugrad.cs.ualberta.ca                       14-Sep-99 12:26:19
  To: All                                               14-Sep-99 20:40:17
Subj: AbiWord

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

I came across an interresting project the other day:
  www.abisource.com

Their goal is to create desktop applications under an open source license
(which, for the end-user means it's free).  They've already done some
progress on AbiWord -- a word processor.

So far, they have ports for UNIX, Win 95/98/NT, and BeOS.  A Mac port is
in progress.  But no OS/2...

I think this would be a worthwile project, and I'm sure that they would be
happy if a bunch of OS/2 gurus offered their help.  If you are
interrested, you can go to the page listed above, click on Download (under
Products, not Developer), and then on Other (under the platforms).

Hubert.

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

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

From: abuse@orac.clara.co.uk                            14-Sep-99 19:14:02
  To: All                                               14-Sep-99 20:40:17
Subj: Re: Q: Problem reading from partitions > 4GB

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

On Mon, 13 Sep 99 08:31:26, Hans K. Aspenberg <hka@norman.no> wrote:

>The enclosed code tries to open all drives logically, from "A:" to "Z:" and
>read the first sector off each drive. It works like a charm for all types of
>disks, except for hard disk partitions > 4GB where DosRead() returns rc=5
>ERROR_ACCESS_DENIED. (By the way, it works for > 4GB partitions when the

Get OS2UNDOC from Hobbes and look at the HPFS Large Disk Access section.

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

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

From: abuse@orac.clara.co.uk                            14-Sep-99 19:13:29
  To: All                                               14-Sep-99 20:40:17
Subj: Re: Combo boxes and bitmaps

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

On Fri, 10 Sep 1999 18:58:23 +0800, Ian Harvey <ian_harvey@do.not.spam.me>
wrote:

>The file selection control is a container.  The combo-box like drive
>selection control appears to be a custom control.

From my observations, I think you have it backwards... the drive/directory
pane
on the left is a Container, the file selection pane on the right is a custom
control (class PMViewCnrCtlViewWnd).
The only combo-box like thing I see is for the Types. Or are we both talking
about different things? :-)

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

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

From: adammadder@aol.com                                14-Sep-99 22:18:13
  To: All                                               15-Sep-99 03:00:27
Subj: LOLITAS - Free Thumbnailed Pics 52411

From: adammadder@aol.com

LOLITAS AND MORE FOR FREE:

http://207.240.225.250



g.PqgU2BC@

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

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

From: hka@norman.no                                     15-Sep-99 09:20:13
  To: All                                               15-Sep-99 11:00:22
Subj: Re: Q: Traversion partition tables on large disks

From: "Hans K. Aspenberg" <hka@norman.no>

On Tue, 14 Sep 99 15:16:15 +0100, Hans K. Aspenberg wrote:

It's a bad habit answering myself, (schizophrenic?) but I found a solution to
the problem. Perhaps someone else could have use of it.

My assumptions below are correct. It is documented in
"http://magic.hurrah.com/~sabre/os/S2Partitions/PartitionTables.txt" among
other places, but this is the best reference on partition tables I've found.

;-)) Hans

:>Hi all,
:>
:>While traversing partition tables on a 10.2 GB disk (which used to ba a
large
:>disk) I have encountered the following:
:>
:>The partition table in the MBR is as follows:
:>
:>   PartnTable in MBR
:>   0000: 00 00 01 01 05 0E FF FF B1 03 00 00 35 27 2A 01 ............5'*.
:>   0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
:>   0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
:>   0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
:>
:>[0] 0x00= Passive, start at CHS(1,0,1), type 5 which is Extended.
:>
:>Reading sector CHS(1,0,1) I get the following:
:>
:>   PartnTable
:>   0000: 80 01 01 01 07 0E FF FF 3F 00 00 00 E2 E6 8D 00 ........?.......
:>   0010: 00 0E FF FF 05 0E FF FF 21 E7 8D 00 14 40 9C 00 ........!....@..
:>   0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
:>   0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
:>
:>[0] 0x80= Active, start at CHS(1,1,1), type 7 which is IFS (HPFS).
:>    This is OK. Reading CHS(1,1,1) reveils a SBS as expected.
:>
:>[1] 0x80= Passive, start at CHS(3FF,1,3F) ends the same place (!)
:>    
:>Reading CHS(3FF,1,3F) obtains random data. Using the .ulBootSectorOffset in
:>the partition entry and reading logical sector 008DE721 reveils the correct
:>SBS. 
:>
:>Back to the question: When having disks larger than the CHS data in a
:>partition entry can describe; can 0E-FFFF in both start-sector and
end-sector
:>be interpreted as a marker saying that "now it is time to read logical"? 
:>
:>;-)) Hans
:>---
:>
:>Hans K. Aspenberg
:>hka@norman.no
:>
:>

---

Hans K. Aspenberg
hka@norman.no


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

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

From: nospam@nospam.com                                 15-Sep-99 12:59:09
  To: All                                               15-Sep-99 20:07:15
Subj: long emx gcc warning messages do not appear

From: nospam@nospam.com (Bruce LaZerte)

/* Filename: test.c
This program illustrates a problem with *long* warning messages not 
appearing when using OS/2's command line to compile with EMX 0.9d GNU 
compiler:

gcc -c test.c

When compiled on the command line there is no warning message. 
When compiled within the Med editor, a long message (>256 chars) appears:

"Warning: passing char * as argument 1 of DosFindFirst(const unsigned char 
*,...)  changes signedness".

The identical problem occurs when I try to compile using dmake: no error 
message. What's worse, when I run dmake from within Med, the error messages
are also lost. 

I know how to make this error message go away, and I understand what it is 
talking about. My concern is that I may occasionally miss an important 
warning.

Shorter warnings and errors appear just fine, so I suspect the problem has 
something to do with a 256 char limit in the command shell and dmake (?)

Is there a gcc command line option or something that will fix this? I see 
nothing in the docs.
*/

#define  INCL_DOS
#include <os2.h>
int main (int argc, char **argv)   {
   FILEFINDBUF3  findBuffer  ;
   HDIR findHandle  = 0xFFFFFFFF ;
   int  findCount   = 1 ;
   USHORT rc ;
   char path[256] = "E:/" ;

   rc = DosFindFirst(path        ,
                     &findHandle ,
                     FILE_DIRECTORY  ,
                     &findBuffer ,
                     (ULONG)sizeof(findBuffer) ,
                     (PULONG)&findCount ,
                     (ULONG)0x0001);
   return 0;
   }

----------------------
Bruce LaZerte 	
Muskoka,Ontario,Canada
freshwat at muskoka dot com	

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

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

From: glen@rockyhorror.Zkaroo.co.uk                     15-Sep-99 15:20:00
  To: All                                               15-Sep-99 20:07:15
Subj: Re: long emx gcc warning messages do not appear

From: glen@rockyhorror.Zkaroo.co.uk (Glen D)

You could redirect the error messages to a file using 2>,
eg.
	gcc -c test.c 2> errors.log


On Wed, 15 Sep 1999 12:59:19, nospam@nospam.com (Bruce LaZerte) wrote:

> /* Filename: test.c
> This program illustrates a problem with *long* warning messages not 
> appearing when using OS/2's command line to compile with EMX 0.9d GNU 
> compiler:
> 
> gcc -c test.c
> 
> When compiled on the command line there is no warning message. 
> When compiled within the Med editor, a long message (>256 chars) appears:
> 
> "Warning: passing char * as argument 1 of DosFindFirst(const unsigned char 
> *,...)  changes signedness".
> 
> The identical problem occurs when I try to compile using dmake: no error 
> message. What's worse, when I run dmake from within Med, the error messages
> are also lost. 
> 
> I know how to make this error message go away, and I understand what it is 
> talking about. My concern is that I may occasionally miss an important 
> warning.
> 
> Shorter warnings and errors appear just fine, so I suspect the problem has 
> something to do with a 256 char limit in the command shell and dmake (?)
> 
> Is there a gcc command line option or something that will fix this? I see 
> nothing in the docs.
> */
> 
> #define  INCL_DOS
> #include <os2.h>
> int main (int argc, char **argv)   {
>    FILEFINDBUF3  findBuffer  ;
>    HDIR findHandle  = 0xFFFFFFFF ;
>    int  findCount   = 1 ;
>    USHORT rc ;
>    char path[256] = "E:/" ;
> 
>    rc = DosFindFirst(path        ,
>                      &findHandle ,
>                      FILE_DIRECTORY  ,
>                      &findBuffer ,
>                      (ULONG)sizeof(findBuffer) ,
>                      (PULONG)&findCount ,
>                      (ULONG)0x0001);
>    return 0;
>    }
> 
> ----------------------
> Bruce LaZerte 	
> Muskoka,Ontario,Canada
> freshwat at muskoka dot com	


Glen D
-<remove Z from my e-mail address>-

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

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

From: nospam@nospam.com                                 15-Sep-99 18:47:18
  To: All                                               15-Sep-99 20:07:15
Subj: Re: long emx gcc warning messages do not appear

From: nospam@nospam.com (Bruce LaZerte)

On Wed, 15 Sep 1999 15:20:01, glen@rockyhorror.Zkaroo.co.uk (Glen D) wrote:

Good idea... just tried it...unfortunately, it doesn't help... sigh. 

> You could redirect the error messages to a file using 2>,
> eg.
>         gcc -c test.c 2> errors.log
> 

----------------------
Bruce LaZerte 	
Muskoka,Ontario,Canada
freshwat at muskoka dot com	

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

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

From: hubert@ugrad.cs.ualberta.ca                       15-Sep-99 11:53:28
  To: All                                               15-Sep-99 20:07:15
Subj: Re: long emx gcc warning messages do not appear

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

Try
  gcc -Wall -c test.c

-W selects different warnings to display.  -Wall turns on all warnings.

On Wed, 15 Sep 1999, Bruce LaZerte wrote:

> /* Filename: test.c
> This program illustrates a problem with *long* warning messages not 
> appearing when using OS/2's command line to compile with EMX 0.9d GNU 
> compiler:
> 
> gcc -c test.c
> 
> When compiled on the command line there is no warning message. 
> When compiled within the Med editor, a long message (>256 chars) appears:
> 
> "Warning: passing char * as argument 1 of DosFindFirst(const unsigned char 
> *,...)  changes signedness".

[cut]

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

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

From: nospam@nospam.com                                 15-Sep-99 18:47:19
  To: All                                               15-Sep-99 20:07:15
Subj: Re: long emx gcc warning messages do not appear

From: nospam@nospam.com (Bruce LaZerte)

On Wed, 15 Sep 1999 17:53:57, Hubert Chan <hubert@ugrad.cs.ualberta.ca> 
wrote:

The warning I'm seeing in Med appears without any -W setting. On the 
command line, -Wall doesn't help with this long one. Thanks anyway...

> Try
>   gcc -Wall -c test.c
>  
> -W selects different warnings to display.  -Wall turns on all warnings.

----------------------
Bruce LaZerte 	
Muskoka,Ontario,Canada
freshwat at muskoka dot com	

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

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

From: ilya@math.ohio-state.edu                          15-Sep-99 21:07:12
  To: All                                               16-Sep-99 04:30:10
Subj: Re: long emx gcc warning messages do not appear

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

[A complimentary Cc of this posting was sent to Bruce LaZerte
<nospam@nospam.com>],
who wrote in article <bsV3ehsibPZd-pn2-nkRH7LjOUfKW@ASUSP2333>:
> /* Filename: test.c
> This program illustrates a problem with *long* warning messages not 
> appearing when using OS/2's command line to compile with EMX 0.9d GNU 
> compiler:
> 
> gcc -c test.c
> 
> When compiled on the command line there is no warning message. 
> When compiled within the Med editor, a long message (>256 chars) appears:
> 
> "Warning: passing char * as argument 1 of DosFindFirst(const unsigned char 
> *,...)  changes signedness".

I added

 int foo(unsigned char *p);

 rc = foo(path);

to your file and did not get any message either.  Thus this is not a
problem with length (as it should not be).  Are you sure you were
calling gcc?  Try adding -v option on the command line.

> The identical problem occurs when I try to compile using dmake: no error 
> message. What's worse, when I run dmake from within Med, the error messages
> are also lost. 

Just guessing...  Check your PATH etc environment variables.  

Probably MED calls gcc without calling a shell, and all other ways to
call things have a loaded shell in between.  Probably your shell loads
some initialization file which changes environment variables.

Ilya

P.S.  Try to reproduce this problem with user-defined function, so the
      message is shorter.  This may reveal more things.

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

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

From: nospam@nospam.com                                 15-Sep-99 23:37:26
  To: All                                               16-Sep-99 04:30:10
Subj: Re: long emx gcc warning messages do not appear

From: nospam@nospam.com (Bruce LaZerte)

On Wed, 15 Sep 1999 21:07:25, ilya@math.ohio-state.edu (Ilya Zakharevich) 
wrote:

> I added
>  
>  int foo(unsigned char *p);
>  
>  rc = foo(path);
>  
> to your file and did not get any message either.  Thus this is not a
> problem with length (as it should not be).  

A good test and I agree, length of the warning message cannot be the 
problem. 

> Are you sure you were
> calling gcc?  Try adding -v option on the command line.

AHA! Thank you, thank you, thank you.

The name of the file was actually: test.C
Note the capital C! 

The Med editor passed this file name exactly as specified to gcc which 
called cc1plus.exe in the second pass, thinking it was a C++ file. However 
on the command line, I was just typing in "gcc -c test.c". Even though the 
file was named "test.C", this was ignored by gcc, and it called cc1.exe 
(not cc1plus.exe) on the second pass.

If I type in "gcc -c test.C" on the command line,  I now get the same 
warning messages as in the Med editor. Wow!

It *is* a bit surprising that  cc1.exe and cc1plus.exe behave so 
differently with respect to warning messages. The cc1plus.exe seems more 
rigorous. Unfortunately I see nothing in the documentation about this.

Many thanks for your help and suggestions.

----------------------
Bruce LaZerte 	
Muskoka,Ontario,Canada
freshwat at muskoka dot com	

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

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

From: hunters@thunder.indstate.edu                      15-Sep-99 23:45:22
  To: All                                               16-Sep-99 04:30:10
Subj: What causes "Exiting Thread 1" hang?

From: hunters@thunder.indstate.edu


I'm sure we all remember the early days of NS 2.02 when it would crash
and then hang while (according to WatchCat, etc) "Exiting Thread 1..."
and was thus unkillable while leaving the display corupted.

Whose falt is this? The program for being coded badly, or OS/2 for not
handeling it properly?

I ask because I tried to run the Quake3_test using Win32-OS/2 (A.04),
and it very nearly does something usefull. I get the start-up screen,
where I am informed on what OS version I'm using (NT 4 it says), my CPU
(correct as an AMD w/3DNow!), and that it is now going to load the dll
"3dfxVGL.dll" in "e:\os2\system" (which does not exist mind you). Then
the hard drive goes nuts and nothing happens. Switching to Watchcat
reveals that Q3_test.exe is "Exiting Thread 1...". And the video is
corrupt just like NS/2 2.02... (The pmtree hack doesn't work.)

Unfortunatly, the Win32os2.log file is never written to, and I don't
know how far it gets... So anyway, just wondering. Thanks in advance!

--
-Steven Hunter               *OS/2 Warp 4 * |Warpstock '99 | Oct 16-17|
hunters@thunder.indstate.edu *AMD K6-2 400* |       Atlanta GA        |


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Deja.com - Share what you know. Learn what you do
(1:109/42)

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

From: fmesnier@dial.oleane.com                          16-Sep-99 05:12:27
  To: All                                               16-Sep-99 04:30:10
Subj: vacpp install & matrox driver

From: Franck Mesnier <fmesnier@dial.oleane.com>

Hello

I come just to install VACPP 4.0 for OS/2 for the second time and I have
always

the same problem :
As soon as I run VACPP, it hangs the system after the main window after the  
display of the logo, and the main window is not display completly.
I have a matrox G400 with the driver 2.31.095 in 1024x768.
I have tried with other resolutions but that does not work more, safe in  vga 
640x480x256 colors.
I install the fixpack 2, but not the fixpack 1 because I have the error 3 (?) 
message in wpinstall.log file.

What then  I can try now ?



Thanks


Franck

-----------------------------------
From the OS/2 WARP v4 fp10
Desktop of Franck MESNIER
34140 LOUPIAN
FRANCE
fmesnier@dial.oleane.com
ICQ : 26368765
-----------------------------------

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

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

From: rpawlitzek@my-deja.com                            16-Sep-99 03:24:17
  To: All                                               16-Sep-99 04:30:10
Subj: Petzold OS/2 PM Programming book for sale

From: rpawlitzek@my-deja.com

I am selling my copy of Petzold's OS/2 PM Programming book:

http://cgi.ebay.com/aw-cgi/eBayISAPI.dll?ViewItem&item=165419421

OS/2 Presentation Manager Programming Book by Charles Petzold,
published by Ziff-Davis Press, ISBN 1-56276-123-4, 934 pages,
this book is no longer available and is a collector's item,
it is still one of the best starting points for OS/2 application
programming, description: "PC Magazine operation system wizard
Charles Petzold shows how to write superior OS/2 programs that
take full advantage of the Presentation Manager features.
Includes a disk with code for the dozens of programs
demonstrated in the text."


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Deja.com - Share what you know. Learn what you do
(1:109/42)

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

From: mike@nospam.mendelu.cz                            15-Sep-99 21:47:28
  To: All                                               16-Sep-99 21:19:10
Subj: Re: One for the EMX gurus...

From: Michal Necasek <mike@nospam.mendelu.cz>

Marty wrote:

> kenames@earthlink.net wrote:
> >
> > damn Marty, thats a big one! are you trying to emulate windows?
>
> Heh.. not yet.  ;-)
>
> MAME has quite a few symbols defined.  Stripping out the symbolic info, the
> executable is a paltry 8MB.  ;-)
>
 Hmm, just today I tried to build some stuff with both emx and VAC++. 
The executable without debug info is about 800K. With debug info it's 
1.960.734 bytes from VAC++ vs. 7.252.563 bytes from emx/gcc! 
That's a helluva difference! Does anyone have some idea about how to 
reduce the emx-produced executable size?

> Now all I have to do is figure out how to use this PMGDB.  It keeps
> complaining about being started in a VIO window and that it could lock my
> system if I use it to debug a PM app.
>
 Yeah, that's why I rebuilt my project with VAC++. IPMD has no 
seroius competition - except ICAT of course but that's just an 
IPMD-like front-end to kernel debugger. 
 

     - Mike

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: PVT a.s., Czech Republic (1:109/42)

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

From: hei@hatespam.norman.no                            16-Sep-99 06:43:03
  To: All                                               16-Sep-99 21:19:10
Subj: Re: long emx gcc warning messages do not appear

From: hei@hatespam.norman.no (Harald Eilertsen)

On Wed, 15 Sep 1999 23:37:52, nospam@nospam.com (Bruce LaZerte) wrote:

> It *is* a bit surprising that  cc1.exe and cc1plus.exe behave so 
> differently with respect to warning messages. 

C++ compilers usually are a bit more demanding, and put out more error
and warning messages than straight C compilers. It's not a particular 
gcc thing. If you're writing a straight C program, you may want to 
rename the file to have a small "c" so you'll allways compile with the
plain C compiler.

Take Care!
--
Harald Eilertsen
Norman Data Defence Systems
http://www.norman.no/

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

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

From: ilya@math.ohio-state.edu                          16-Sep-99 07:30:00
  To: All                                               16-Sep-99 21:19:10
Subj: Re: One for the EMX gurus...

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

[A complimentary Cc of this posting was sent to Michal Necasek 
<mike@nospam.mendelu.cz>],
who wrote in article <37E005FD.AF7EF22E@nospam.mendelu.cz>:
>  Hmm, just today I tried to build some stuff with both emx and VAC++. 
> The executable without debug info is about 800K. With debug info it's 
> 1.960.734 bytes from VAC++ vs. 7.252.563 bytes from emx/gcc! 
> That's a helluva difference! Does anyone have some idea about how to 
> reduce the emx-produced executable size?

What for?

Ilya

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

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

From: hellwig@exp.bessy.de                              16-Sep-99 12:30:05
  To: All                                               16-Sep-99 21:19:11
Subj: rshd: CR->CR+LF

From: Chris Hellwig <hellwig@exp.bessy.de>

Hi,

I found that rshd converts a ASCII '0x0d' to '0x0d 0x0a'

Is there a way (or an alternate rshd.exe) wich uses a 
plain binary mode?

Chris

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

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

From: mamodeo@stny.rr.com                               16-Sep-99 09:49:04
  To: All                                               16-Sep-99 21:19:11
Subj: Re: What causes "Exiting Thread 1" hang?

From: Marty <mamodeo@stny.rr.com>

hunters@thunder.indstate.edu wrote:
> 
> I'm sure we all remember the early days of NS 2.02 when it would crash
> and then hang while (according to WatchCat, etc) "Exiting Thread 1..."
> and was thus unkillable while leaving the display corupted.
> 
> Whose falt is this? The program for being coded badly, or OS/2 for not
> handeling it properly?

I think it's more of the programmer's fault.  OS/2 grants the
application some trust that it will not have a critical failure in its
exit routines.  This problem usually happens when an application's exit
routine blocks for some reason, and there is nothing left running that
would normally unblock it.

- Marty

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: IBM Global Services North -- Burlington, Vermont,
(1:109/42)

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

From: nospam@nospam.com                                 16-Sep-99 16:40:04
  To: All                                               16-Sep-99 22:38:01
Subj: PM window resizing/clipping : seems backwards... 

From: nospam@nospam.com (Bruce LaZerte)

I'm bothered about how a client window is resized and clipped in PM 
programming.

If the top frame border is moved down, the whole client window is shifted 
down and clipping is at the bottom of the client window. If the bottom 
border is moved up, clipping is again at the bottom but the client is not 
shifted. I would think clipping should be done at the top of the window in 
both cases  because the client window's origin for painting is at the 
bottom (left) in OS/2. 

This behaviour makes maintaining the window during sizing redraws trickier 
when not using the CS_SIZEREDRAW flag. I ended up positioning graphical 
elements relative to the upper left corner of the window which, of course, 
requires more calculation than positioning with respect to the bottom left,
the origin.

Can this clipping behaviour be changed? Is there any reason why it's this 
way?

It's not a problem when moving the left and right frame borders as clipping
is always on the right and the drawing origin is on the left.

----------------------
Bruce LaZerte 	
Muskoka,Ontario,Canada
freshwat at muskoka dot com	

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

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

From: mamodeo@stny.rr.com                               16-Sep-99 18:21:00
  To: All                                               17-Sep-99 03:55:00
Subj: EMXBIND earns its name...

From: Marty <mamodeo@stny.rr.com>

On a related note to the 31MB executable in another thread, I've found out
something very disturbing with EMXBIND.  I don't know if EMXBIND itself,
OS/2 itself, or the EMX runtime is to blame.

When I run EMXBIND on this executable to add PM resources (.RES) to it, it
has about a 50% chance of completely and entirely locking up my system!  It
doesn't crash, it doesn't slow things up while it's working and then free
back up, it literally grinds to a halt, getting slower and slower until no
further input is accepted in any form.  The cursor in the VIO session slows
down and stops blinking.  My hard drive stops thrashing about.  CTRL-ESC
does nothing.  The WatchCat keystroke gives the characteristic "BEEP" but
WatchCat never kicks in.  CTRL-ALT-DEL does not even function.  This only
happens with a very large executable.

I watched the swapfile once while it was executing and I saw all of my free
memory consumed and my swapper grow by 32MB in under 1 second.  It is
usually at this "intense" point that the system locks if it is going to.

Besides stripping out the debug info, does anyone have any suggestions as
to what can be done to minimize this risk?  Any thoughts as to what is
actually happening?

One more side issue:
Has anyone else noticed that when you run GCC on a file that takes a long
time to compile that the VIO window in which you ran it doesn't like to
give up the window focus?  Any ideas why this could happen?

[FYI:  I'm working with PGCC (with the -pipe switch if that matters), but
I've seen the same problem with GCC]

- Marty

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

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

From: DLaRue@NetSRQ.Com                                 17-Sep-99 01:27:06
  To: All                                               17-Sep-99 03:55:00
Subj: Re: Help converting Borland c to VAC on OS2

From: DLaRue@NetSRQ.Com (David LaRue)

  Hello Blake,

  You may find more expertise on this matter by checking IBM's News Site.  I
know
of several persons who visit there more than here.  IBMs site is 
News.Software.IBM.Com.  The *.vacpp fourums are your best bet.

  Good luck,

  David LaRue

In <37E134E0.A720D167@ddp.ca>, Blake Whitelaw <blake_whitelaw@ddp.ca> writes:
>I have to covert a Borland C project to a VAC project and recompile. 
>Can anyone give me any pointers as to the best way to go about this.  I
>come from the Windows world and this is my first excision into VAC++.
>
>Thanks
>Blake
>
>-- 
>-----------------------------------------------------------
>Blake Whitelaw
>DDP Consulting Group, Vancouver BC Canada
>Phone: 604-294-9193  Fax: 604-294-9155
>Web Page: http://www.ddp.ca
>mailto:blake_whitelaw@ddp.ca
>-----------------------------------------------------------

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

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

From: ian_harvey@do.not.spam.me                         17-Sep-99 18:33:27
  To: All                                               17-Sep-99 11:01:03
Subj: Re: PM window resizing/clipping : seems backwards...

From: Ian Harvey <ian_harvey@do.not.spam.me>

Try handling the WM_CALCVALIDRECTS message in your window procedure to
change the rectangle preservation behaviour from the default (which is
top left alignment as you have observed).

case WM_CALCVALIDRECTS:
   return MRFROMLONG(CVR_ALIGNBOTTOM | CVR_ALIGNLEFT);

Bruce LaZerte wrote:
> 
> I'm bothered about how a client window is resized and clipped in PM
> programming.
> 
> If the top frame border is moved down, the whole client window is shifted
> down and clipping is at the bottom of the client window. If the bottom
> border is moved up, clipping is again at the bottom but the client is not
> shifted. I would think clipping should be done at the top of the window in
> both cases  because the client window's origin for painting is at the
> bottom (left) in OS/2.
...
> 
> Can this clipping behaviour be changed? Is there any reason why it's this
> way?
-- 
IanH
Comments and questions welcome at ian_harvey at bigpond dot com
However, do _not_ send me unsolicited commercial email.

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

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

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