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

                 Saturday, 28-Aug-1999 to Friday, 03-Sep-1999

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

From: jana.persson@telia.com                            27-Aug-99 22:47:04
  To: All                                               28-Aug-99 03:31:24
Subj: Image compression?

From: "Jan A" <jana.persson@telia.com>

Anyone know of any REALLY efficient image compression utility? The type
image I need compressed is a 200 dpi/256 grays with mostly printed text and
lines on it. In the BMP format, the image is just above 1 MB in size and I
need it to be under 10K. Lossy compression OK but have to be able to read
handwritten text after decompression and printout.

The amount of grays is actually mostly noise, so the closest I've come this
far was to reduce the amount of grays to 2 and use GIF89a, that took it down
to some 17K. But I desperately need to get rid of another 10K or so. Would
IFS do it (fractals)? Wavelets? I have no experience with those.

A clue, anyone?

/Jan A

jana@tumbleweedtrail.com


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

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

From: steve53_remove_this@earthlink.net                 27-Aug-99 17:14:17
  To: All                                               28-Aug-99 03:31:25
Subj: Re: LX file format?

From: steve53_remove_this@earthlink.net

In <7q6um4$iii$1@nusku.cts.com>, on 08/27/99 
   at 09:07 PM, Will Rose <cwr@cts.com> said:

>I've got most of the format details from Viscuso's book, but I don't

Did the INF I emailed help?

>understand the LX header value 'object iterated pages offset'.  I'd
>expect it to be the offset of the iterated data pages, but it doesn't
>seem to point to something like that in the files I've looked at. 

It is.  However, as I read the spec, the data pages all share the same
area and this just points to the same base as the other data pages offset. 
The iterated pages table is used to find the iterated pages.

BTW, hope you don't have to patch one of them. :)

>My other problem is that some 32-bit records in the entry name table have
>a flag value of 3, rather than 1 or 0xf8 which are the only two valid
>flags I can find. (f8 is a mask).  What does the second bit do?

I can't find that.  Are you sure you are not looking at the next type 3
entry?

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: thannymeister@spambegone.yahoo.com                28-Aug-99 04:14:05
  To: All                                               28-Aug-99 10:43:13
Subj: Re: atoi access exception

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

On Fri, 27 Aug 1999 12:16:42 -0500 (CDT), Scott E. Garfinkle wrote:

>On Fri, 27 Aug 1999 11:24:49 -0400 (EDT), Mike Ruskai wrote:
>
>>Neither do you, apparently.  cpTest is indeed a pointer. 

>Although extremely obnoxious, he iscertainly technically correct here, and
>you are wrong.
>The name "cpTest" is bound to an array. This is NOT the same as a pointer,
>though there are many similarities. One of the several differences is, in
>fact, in the sizeof() operator, where sizeof(cpTest) is 64 here, where if
>cpTest where a pointer, it would be 4 (or 2 or whatever, depending on the
>architecture). 

It certainly is bound to an array, which does allow sizeof() to return the
array size, as I said in the part of my post you snipped out, but it is also
in fact a pointer.  The value of cpTest is the address of the first element
of the array.  You can assign that value to an explicitly declared pointer. 
You can dereference that pointer.  In fact, it behaves in every way as a
pointer.  There are very few differences indeed beyond the return value of
sizeof().


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: thannymeister@spambegone.yahoo.com                28-Aug-99 04:17:22
  To: All                                               28-Aug-99 10:43:13
Subj: Re: LX file format?

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

On 27 Aug 1999 21:07:16 GMT, Will Rose wrote:

>Much to my annoyance I've had to dis-assemble and patch an LX-format DLL.
>I've got most of the format details from Viscuso's book, but I don't
>understand the LX header value 'object iterated pages offset'.  I'd expect
>it to be the offset of the iterated data pages, but it doesn't seem to
>point to something like that in the files I've looked at. 
>
>My other problem is that some 32-bit records in the entry name table have
>a flag value of 3, rather than 1 or 0xf8 which are the only two valid
>flags I can find. (f8 is a mask).  What does the second bit do?
>
>Anyone have any answers to these questions, or a place where I could look?

While I certainly don't know enough to provide details, you should remember
that LX executables can be compressed.  OS/2 2.1 could decompress only the
data portion, but Warp 3 and above can decompress both code and data.

The ones you are working with may be compressed, which would certainly alter
the structure.  There is a program called LXLite which you can use to
decompress the executable, if that is in fact what the problem is.


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: aaronl@clear.net.nz                               29-Aug-99 00:02:13
  To: All                                               28-Aug-99 10:43:14
Subj: Re: Image compression?

From: Aaron Lawrence <aaronl@clear.net.nz>

Jan A wrote:

> Anyone know of any REALLY efficient image compression utility? The type
> image I need compressed is a 200 dpi/256 grays with mostly printed text and
> lines on it. In the BMP format, the image is just above 1 MB in size and I
> need it to be under 10K. Lossy compression OK but have to be able to read
> handwritten text after decompression and printout.
>
> The amount of grays is actually mostly noise, so the closest I've come this
> far was to reduce the amount of grays to 2 and use GIF89a, that took it down
> to some 17K. But I desperately need to get rid of another 10K or so. Would
> IFS do it (fractals)? Wavelets? I have no experience with those.

Have you tried it with jpeg? That's the obvious thing you haven't mentioned.
It
might work ok. The result will look pretty bad but...

If you can find a wavelet codec for OS/2 that would probably do it, though
again
I don't think it is designed for black and white.

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: CLEAR Net New Zealand (1:109/42)

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

From: dmcbride@no.tower.spam.to.org                     28-Aug-99 14:18:05
  To: All                                               28-Aug-99 14:21:24
Subj: Re: atoi access exception

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

On Sat, 28 Aug 1999 04:14:11 -0400 (EDT), Mike Ruskai wrote:

>On Fri, 27 Aug 1999 12:16:42 -0500 (CDT), Scott E. Garfinkle wrote:
>
>>On Fri, 27 Aug 1999 11:24:49 -0400 (EDT), Mike Ruskai wrote:
>>
>>>Neither do you, apparently.  cpTest is indeed a pointer. 
>
>>Although extremely obnoxious, he iscertainly technically correct here, and
>>you are wrong.
>>The name "cpTest" is bound to an array. This is NOT the same as a pointer,
>>though there are many similarities. One of the several differences is, in
>>fact, in the sizeof() operator, where sizeof(cpTest) is 64 here, where if
>>cpTest where a pointer, it would be 4 (or 2 or whatever, depending on the
>>architecture). 
>
>It certainly is bound to an array, which does allow sizeof() to return the
>array size, as I said in the part of my post you snipped out, but it is also
>in fact a pointer.  The value of cpTest is the address of the first element

It also, in fact, is *not* a pointer, but an "array type" [ANSI/ISO 9899/1990
6.1.2.5].

What you're saying is akin to saying that a short is a long because you can
use a short where you can use a long.  The fact that a variable of "array
type" can be cast to "pointer" implicitly no more makes an array a pointer
than the fact that a short can be cast to a long implicitly makes a short a
long.

>of the array.  You can assign that value to an explicitly declared pointer. 

No - you can *implicitly* (or explicitly) *cast* an array type to a pointer
to the array's element type.

>You can dereference that pointer.  In fact, it behaves in every way as a
>pointer.  There are very few differences indeed beyond the return value of
>sizeof().

Sizeof isn't a function.  It's an operator.  And as such, the "return value"
is a critical difference.

Also, if you want to be accurate, the array object acts more like a const
pointer to element ("<element>* const") than a normal pointer, since you
cannot assign to it.  But this still doesn't make the array object a pointer,
just describes its behaviour.

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



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

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

From: stantowianski@home.com                            28-Aug-99 18:14:22
  To: All                                               28-Aug-99 21:13:09
Subj: Pipes( > < | )  do text only?

From: Stan Towianski <stantowianski@home.com>

Hi,

I wrote a cat.exe which write out a file's contents in binary.
I think the program is working, but when I redirect is with
| or > I think these are only allowing text mode file operations!

For example, if I do cat.exe config.sys > out
and the file had 7800 bytes in 50 lines, out will have a size of 7850.
I think it is adding a CR after each LF for each line.

If I cat a binary file and | it to another program who writes it to
a 2nd file the binary file gets cut off just like if you try to do:
type binary_filename and it cuts the file off because of some char.

This seems pathetic ! !  I would think OS/2 is doing it?
Any know if this is true and how to fix it?

Thanks.


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

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

From: mamodeo@stny.rr.com                               28-Aug-99 17:17:05
  To: All                                               29-Aug-99 05:35:21
Subj: Re: atoi access exception

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

Darin McBride wrote:
> 
> >It certainly is bound to an array, which does allow sizeof() to return the
> >array size, as I said in the part of my post you snipped out, but it is
also
> >in fact a pointer.  The value of cpTest is the address of the first element
> 
> It also, in fact, is *not* a pointer, but an "array type" [ANSI/ISO
9899/1990
> 6.1.2.5].
> 
> What you're saying is akin to saying that a short is a long because you can
> use a short where you can use a long.  The fact that a variable of "array
> type" can be cast to "pointer" implicitly no more makes an array a pointer
> than the fact that a short can be cast to a long implicitly makes a short a
> long.

There's no casting involved.  If you say:
char *ptr;
ptr = malloc(64);

versus:
char ptr[64];

The only difference is where the storage is allocated from (due to the
malloc itself) and what sizeof returns.  I challenge you to prove
otherwise.  If you look at the assembly code produced by the compiler, you
would see that it gets accessed in the same way, other than the fact that
in the second case it may be located on the stack frame.  In a casting
situation, the compiler produces extra assembly code to convert the one
type to another.
 
> >of the array.  You can assign that value to an explicitly declared pointer.
> 
> No - you can *implicitly* (or explicitly) *cast* an array type to a pointer
> to the array's element type.
> 
> >You can dereference that pointer.  In fact, it behaves in every way as a
> >pointer.  There are very few differences indeed beyond the return value of
> >sizeof().
> 
> Sizeof isn't a function.  It's an operator.  And as such, the "return value"
> is a critical difference.

It's a precompiler macro.  It doesn't actually exist in your code and is
replaced with a constant.

> Also, if you want to be accurate, the array object acts more like a const
> pointer to element ("<element>* const") than a normal pointer, since you
> cannot assign to it.

True.

> But this still doesn't make the array object a pointer, just describes its 
> behaviour.

It is special-cased to behave this way.  It is implemented in assembly the
way a pointer is implemented.

- Marty

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

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

From: cwr@cts.com                                       28-Aug-99 22:50:14
  To: All                                               29-Aug-99 10:42:24
Subj: Re: LX file format?

From: Will Rose <cwr@cts.com>

Mike Ruskai <thannymeister@spambegone.yahoo.com> wrote:
: On 27 Aug 1999 21:07:16 GMT, Will Rose wrote:

:>Much to my annoyance I've had to dis-assemble and patch an LX-format DLL.
:>I've got most of the format details from Viscuso's book, but I don't
:>understand the LX header value 'object iterated pages offset'.  I'd expect
:>it to be the offset of the iterated data pages, but it doesn't seem to
:>point to something like that in the files I've looked at. 
:>
:>My other problem is that some 32-bit records in the entry name table have
:>a flag value of 3, rather than 1 or 0xf8 which are the only two valid
:>flags I can find. (f8 is a mask).  What does the second bit do?
:>
:>Anyone have any answers to these questions, or a place where I could look?

: While I certainly don't know enough to provide details, you should remember
: that LX executables can be compressed.  OS/2 2.1 could decompress only the
: data portion, but Warp 3 and above can decompress both code and data.

: The ones you are working with may be compressed, which would certainly alter
: the structure.  There is a program called LXLite which you can use to
: decompress the executable, if that is in fact what the problem is.

No, I'm messing with the tables, which I don't think can be compressed;
compression can certainly be applied to the code and data, but I don't
care about that.


Will
cwr@crash.cts.com

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

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

From: steve53_remove_this@earthlink.net                 28-Aug-99 16:09:06
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

From: steve53_remove_this@earthlink.net

In <37C851D6.10BAB628@stny.rr.com>, on 08/28/99 
   at 05:17 PM, Marty <mamodeo@stny.rr.com> said:

>The only difference is where the storage is allocated from (due to the
>malloc itself) and what sizeof returns.  I challenge you to prove
>otherwise.  If you look at the assembly code produced by the compiler,

Aw heck, got to jump in.  Simply not always true.  Depends on level of
optimization, intelligence of compiler etc. etc..

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: abuse@orac.clara.co.uk                            28-Aug-99 23:42:14
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

On Fri, 27 Aug 1999 11:02:44 -0400, Marty <mamodeo@stny.rr.com> wrote:

>> >cpTest is a pointer to a character buffer.
>> 
>> No it isn't. It's an array. Clearly you don't know the difference.
>
>The symbol cpTest points to an array.

That is subtley different from what you said. There is still no storage for
this "pointer" like there would be for a real pointer - it is just a number.

>It can be used interchangably as cpTest[index] or *(cpTest+index).

The fact that you dereference them the same way doesn't make a pointer equal
to an array.

>Sorry for trying to help.  Won't make the mistake again.  Ego does not
>need to play a part in this group.

Well you could have phrased it better. Your statement was very definite, and
very wrong. If you'd said something like "Shouldn't sizeof(cpTest) be 4 rather
than 64?" then I wouldn't be writing this.

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

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

From: abuse@orac.clara.co.uk                            28-Aug-99 23:42:15
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

On Fri, 27 Aug 1999 11:24:49 -0400 (EDT), Mike Ruskai
<thannymeister@yahoo.com>
wrote:

>Neither do you, apparently.  cpTest is indeed a pointer.

Suggest you go and read K&R as well then. Then you might learn something...

Pointers are Lvalues and have storage. Arrays are not and the address of its
first element has no storage - it is just a number.

>The fact that sizeof() knows that it points to a length of storage 64 bytes
>long is only because the array was statically declared.

Yes, and that is crucial to the point at hand.

>If...

Big word that.

>...you allocated the memory dynamically

But that wasn't the condition. You have just modified it and invalidated the
argument.

>sizeof() wouldn't know anything other than the fact that the pointer is 4
bytes

Which is exactly my point. It is not a pointer.

>Go and ask you mother why she didn't teach you any manners.
>Being an asshole...

This is classic!

>...guarantees that you won't get help next time around.

Fine, if the "help" is wrong, I don't need it. One thing that really annoys me
is people coming out with statments of fact attempting to correct somebody
else
when they were right all along.

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

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

From: abuse@orac.clara.co.uk                            28-Aug-99 23:42:16
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

On Fri, 27 Aug 1999 12:16:42 -0500 (CDT), Scott E. Garfinkle
<seg@NOSPAM-us.ibm.com> wrote:

>On Fri, 27 Aug 1999 11:24:49 -0400 (EDT), Mike Ruskai wrote:
>
>>Neither do you, apparently.  cpTest is indeed a pointer. 

Thanks.

>Although extremely obnoxious

I hardly think the comment comes under that category. Midly obnoxious maybe.

>he iscertainly technically correct here, and you are wrong

I await an apology from Mr Ruskai. Somehow I doubt it will be forthcoming.

>The name "cpTest" is bound to an array. This is NOT the same as a pointer,

Ah, some sense at last.

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

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

From: abuse@orac.clara.co.uk                            28-Aug-99 23:42:17
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

On Sat, 28 Aug 1999 04:14:11 -0400 (EDT), Mike Ruskai
<thannymeister@yahoo.com>
wrote:

>In fact, it behaves in every way as a pointer.

Really? Well then, in that case perhaps you can tell us all how you change
this pointer to point to something else?

>There are very few differences indeed beyond the return value of sizeof().

And the fact that it is an Rvalue. Well, gee, that's 2 already.

Anyhow, this is all rather irrelevant to this group. If you want to carry on
arguing, I suggest you go and do it in comp.lang.c or somewhere.

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

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

From: dmcbride@no.tower.spam.to.org                     29-Aug-99 00:31:20
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

[Contemplated adding comp.lang.c just for a few others that would agree with
me, but decided against a flame war over such a misunderstanding.]

On Sat, 28 Aug 1999 17:17:10 -0400, Marty wrote:

>Darin McBride wrote:
>> 
>> >It certainly is bound to an array, which does allow sizeof() to return the
>> >array size, as I said in the part of my post you snipped out, but it is
also
>> >in fact a pointer.  The value of cpTest is the address of the first
element
>> 
>> It also, in fact, is *not* a pointer, but an "array type" [ANSI/ISO
9899/1990
>> 6.1.2.5].
>> 
>> What you're saying is akin to saying that a short is a long because you can
>> use a short where you can use a long.  The fact that a variable of "array
>> type" can be cast to "pointer" implicitly no more makes an array a pointer
>> than the fact that a short can be cast to a long implicitly makes a short a
>> long.
>
>There's no casting involved.  If you say:
>char *ptr;
>ptr = malloc(64);
>
>versus:
>char ptr[64];
>
>The only difference is where the storage is allocated from (due to the
>malloc itself) and what sizeof returns.  I challenge you to prove
>otherwise.  If you look at the assembly code produced by the compiler, you

Those two differences (moreso sizeof) is what makes it a different type.  I
don't need to prove anything else.

>would see that it gets accessed in the same way, other than the fact that
>in the second case it may be located on the stack frame.  In a casting
>situation, the compiler produces extra assembly code to convert the one
>type to another.

Take a look at what's on the stack in the two situations.

In the case where you have a char*, the ptr is on the stack, and the memory
being used for the array is elsewhere.  Stack: 4 bytes (usually), heap: 64
bytes.  The ptr is at a constant offset from the stack pointer, but the data
is in a dynamic position in the heap.

In the case where you just have the array, the object (which in this case is
an array of char) is on the stack directly.  There is no pointer.  It is at a
constant offset from the stack pointer.  There are no dynamics.

>> >You can dereference that pointer.  In fact, it behaves in every way as a
>> >pointer.  There are very few differences indeed beyond the return value of
>> >sizeof().
>> 
>> Sizeof isn't a function.  It's an operator.  And as such, the "return
value"
>> is a critical difference.
>
>It's a precompiler macro.  It doesn't actually exist in your code and is

Nope, try again.  According to 6.3.3.4, it's an operator.  It is defined to
not work on dynamic types in C++, and there are no dynamic types in C.  Just
like "2 + 2" results in being compiled to "4" (rather than evaluated at
runtime), sizeof is compiled to its constant value.  The preprocessor cannot
do sizeof since the preprocessor doesn't know anything about structures,
arrays, etc.

>replaced with a constant.

It is compiled into a constant, but not replaced by one by the preprocessor.

>> But this still doesn't make the array object a pointer, just describes its 
>> behaviour.
>
>It is special-cased to behave this way.  It is implemented in assembly the
>way a pointer is implemented.

Then you have a seriously broken compiler.

#ifdef USE_PTR
char* ptr = malloc(64);
#else
char ptr[64];
#endif
int i;

fill_ptr_with_random_data(ptr);  /* takes a char* */
for (i = 0; i < 100; ++i)
{
  printf("%d => %d\n", i, 
         (int)ptr[rand() % 64]);
}

The assembly looks like (crudely because I don't know x86 assembly, only
68000) this for loading the right character for the printf.

  load stackpointer
  add  offset_to_ptr
#ifdef USE_PTR
  load this_pointer
#endif
  add  i
  load this_pointer

They are significantly different since the array is already on the stack. 
Further, your mythical ptr is merely pointing to an array anyway.  An array
object is a distinctly different object than a pointer object according to
the standard.

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



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

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

From: mamodeo@stny.rr.com                               28-Aug-99 21:13:27
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

Paul Ratcliffe wrote:
> 
> On Fri, 27 Aug 1999 11:02:44 -0400, Marty <mamodeo@stny.rr.com> wrote:
> 
> >> >cpTest is a pointer to a character buffer.
> >>
> >> No it isn't. It's an array. Clearly you don't know the difference.
> >
> >The symbol cpTest points to an array.
> 
> That is subtley different from what you said. There is still no storage for
> this "pointer" like there would be for a real pointer - it is just a number.

Gotcha.  I see.
 
> >It can be used interchangably as cpTest[index] or *(cpTest+index).
> 
> The fact that you dereference them the same way doesn't make a pointer equal
> to an array.

I take a very low-level view of things generally.  I tend to view
high-level language constructs as "smoke and mirrors".  Just a matter of
differing perspectives I guess.

> >Sorry for trying to help.  Won't make the mistake again.  Ego does not
> >need to play a part in this group.
> 
> Well you could have phrased it better. Your statement was very definite, and
> very wrong. If you'd said something like "Shouldn't sizeof(cpTest) be 4
rather
> than 64?" then I wouldn't be writing this.

Understood.  No hard feelings.

- Marty

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

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

From: mamodeo@stny.rr.com                               28-Aug-99 21:17:28
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

Darin McBride wrote:
> 
> [Contemplated adding comp.lang.c just for a few others that would agree with
> me, but decided against a flame war over such a misunderstanding.]

That's ok.  You've stated your case clearly enough and I agree.

- Marty
 
> On Sat, 28 Aug 1999 17:17:10 -0400, Marty wrote:
> 
> >Darin McBride wrote:
> >>
> >> >It certainly is bound to an array, which does allow sizeof() to return
the
> >> >array size, as I said in the part of my post you snipped out, but it is
also
> >> >in fact a pointer.  The value of cpTest is the address of the first
element
> >>
> >> It also, in fact, is *not* a pointer, but an "array type" [ANSI/ISO
9899/1990
> >> 6.1.2.5].
> >>
> >> What you're saying is akin to saying that a short is a long because you
can
> >> use a short where you can use a long.  The fact that a variable of "array
> >> type" can be cast to "pointer" implicitly no more makes an array a
pointer
> >> than the fact that a short can be cast to a long implicitly makes a short 
a
> >> long.
> >
> >There's no casting involved.  If you say:
> >char *ptr;
> >ptr = malloc(64);
> >
> >versus:
> >char ptr[64];
> >
> >The only difference is where the storage is allocated from (due to the
> >malloc itself) and what sizeof returns.  I challenge you to prove
> >otherwise.  If you look at the assembly code produced by the compiler, you
> 
> Those two differences (moreso sizeof) is what makes it a different type.  I
> don't need to prove anything else.
> 
> >would see that it gets accessed in the same way, other than the fact that
> >in the second case it may be located on the stack frame.  In a casting
> >situation, the compiler produces extra assembly code to convert the one
> >type to another.
> 
> Take a look at what's on the stack in the two situations.
> 
> In the case where you have a char*, the ptr is on the stack, and the memory
> being used for the array is elsewhere.  Stack: 4 bytes (usually), heap: 64
> bytes.  The ptr is at a constant offset from the stack pointer, but the data
> is in a dynamic position in the heap.
> 
> In the case where you just have the array, the object (which in this case is
> an array of char) is on the stack directly.  There is no pointer.  It is at
a
> constant offset from the stack pointer.  There are no dynamics.
> 
> >> >You can dereference that pointer.  In fact, it behaves in every way as a
> >> >pointer.  There are very few differences indeed beyond the return value
of
> >> >sizeof().
> >>
> >> Sizeof isn't a function.  It's an operator.  And as such, the "return
value"
> >> is a critical difference.
> >
> >It's a precompiler macro.  It doesn't actually exist in your code and is
> 
> Nope, try again.  According to 6.3.3.4, it's an operator.  It is defined to
> not work on dynamic types in C++, and there are no dynamic types in C.  Just
> like "2 + 2" results in being compiled to "4" (rather than evaluated at
> runtime), sizeof is compiled to its constant value.  The preprocessor cannot
> do sizeof since the preprocessor doesn't know anything about structures,
> arrays, etc.
> 
> >replaced with a constant.
> 
> It is compiled into a constant, but not replaced by one by the preprocessor.
> 
> >> But this still doesn't make the array object a pointer, just describes
its
> >> behaviour.
> >
> >It is special-cased to behave this way.  It is implemented in assembly the
> >way a pointer is implemented.
> 
> Then you have a seriously broken compiler.
> 
> #ifdef USE_PTR
> char* ptr = malloc(64);
> #else
> char ptr[64];
> #endif
> int i;
> 
> fill_ptr_with_random_data(ptr);  /* takes a char* */
> for (i = 0; i < 100; ++i)
> {
>   printf("%d => %d\n", i,
>          (int)ptr[rand() % 64]);
> }
> 
> The assembly looks like (crudely because I don't know x86 assembly, only
> 68000) this for loading the right character for the printf.
> 
>   load stackpointer
>   add  offset_to_ptr
> #ifdef USE_PTR
>   load this_pointer
> #endif
>   add  i
>   load this_pointer
> 
> They are significantly different since the array is already on the stack.
> Further, your mythical ptr is merely pointing to an array anyway.  An array
> object is a distinctly different object than a pointer object according to
> the standard.

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

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

From: mamodeo@stny.rr.com                               28-Aug-99 21:20:02
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

Paul Ratcliffe wrote:
> 
> I await an apology from Mr Ruskai. Somehow I doubt it will be forthcoming.

I certainly wish to apologize for being unclear and wrong.

- Marty

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

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

From: mamodeo@stny.rr.com                               28-Aug-99 21:23:28
  To: All                                               29-Aug-99 10:42:25
Subj: Re: atoi access exception

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

Paul Ratcliffe wrote:
> 
> Fine, if the "help" is wrong, I don't need it. One thing that really annoys
me
> is people coming out with statments of fact attempting to correct somebody
else
> when they were right all along.

Well... the original poster was looking for suggestions and things to look
at which could make the code not work as he was seeing.  Whether I was
right or not (which I was not, I fully admit), it was a sanity check for
him at the very least.  I guess I should just stick to DIVE/DART API call
help from now on.  ;-)

- Marty

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

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

From: cwr@cts.com                                       29-Aug-99 13:33:09
  To: All                                               29-Aug-99 15:49:09
Subj: Re: LX file format?

From: Will Rose <cwr@cts.com>

steve53_remove_this@earthlink.net wrote:
: In <7q6um4$iii$1@nusku.cts.com>, on 08/27/99 
:    at 09:07 PM, Will Rose <cwr@cts.com> said:

:>I've got most of the format details from Viscuso's book, but I don't

: Did the INF I emailed help?

:>understand the LX header value 'object iterated pages offset'.  I'd
:>expect it to be the offset of the iterated data pages, but it doesn't
:>seem to point to something like that in the files I've looked at. 

: It is.  However, as I read the spec, the data pages all share the same
: area and this just points to the same base as the other data pages offset. 
: The iterated pages table is used to find the iterated pages.

: BTW, hope you don't have to patch one of them. :)

No, but I finally realised that you can have an iterated data page with
a single iteration.  DAMFINO why...

:>My other problem is that some 32-bit records in the entry name table have
:>a flag value of 3, rather than 1 or 0xf8 which are the only two valid
:>flags I can find. (f8 is a mask).  What does the second bit do?

: I can't find that.  Are you sure you are not looking at the next type 3
: entry?

No, some system DLLs have this flag set on some records, but not on
others; others have it set on all or none.  At the moment it's not
important, but it's the last bit of the puzzle and I'd have liked
to clear it up.

Thanks for the INF file btw. - I already had it in hard copy form, but
the INF is more convenient (and even has the same misprunts, for that
homely touch).


Will
cwr@crash.cts.com

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

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

From: lampsstgt@aol.com                                 29-Aug-99 18:52:05
  To: All                                               29-Aug-99 16:52:17
Subj: Netscape API ?

From: lampsstgt@aol.com (Lamps stgt)

Is there an C/C++ API for the Netscape Communicator? I want to send a
html-page
to the Netscape Communicator from a C-application.
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                            29-Aug-99 21:49:01
  To: All                                               29-Aug-99 19:53:19
Subj: Re: Pipes( > < | )  do text only?

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

On Sat, 28 Aug 1999 18:14:44 GMT, Stan Towianski <stantowianski@home.com>
wrote:

>I wrote a cat.exe which write out a file's contents in binary.
>I think the program is working, but when I redirect is with
>| or > I think these are only allowing text mode file operations!

You are opening the file in text mode by the sound of it, when you really
want binary mode. How you select this is dependant on language/compiler and
you don't say which you are using.....

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

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

From: rmahoney@_REMOVE_THIS_netusa.net                  30-Aug-99 01:33:00
  To: All                                               30-Aug-99 05:29:12
Subj: Re: Netscape API ?

From: rmahoney@_REMOVE_THIS_netusa.net (Robert Mahoney)

On Sun, 29 Aug 1999 18:52:10, lampsstgt@aol.com (Lamps stgt) wrote:

> Is there an C/C++ API for the Netscape Communicator? I want to send a
html-page
> to the Netscape Communicator from a C-application.
> Thomas

  That is all done via DDE.  Take a look at this URL:
http://developer.netscape.com:80/docs/manuals/communicator/DDE/index.h
tm

Bob

--
Robert Mahoney
2Rud Software and Consulting
http://www.netusa.net/~rmahoney

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

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

From: paul_floyd@see.sig                                30-Aug-99 09:33:06
  To: All                                               30-Aug-99 12:22:13
Subj: Re: Image compression?

From: Paul FLOYD <paul_floyd@see.sig>

Jan A wrote:
> 
> Anyone know of any REALLY efficient image compression utility? The type
> image I need compressed is a 200 dpi/256 grays with mostly printed text and
> lines on it. In the BMP format, the image is just above 1 MB in size and I
> need it to be under 10K. Lossy compression OK but have to be able to read
> handwritten text after decompression and printout.
> 
> The amount of grays is actually mostly noise, so the closest I've come this
> far was to reduce the amount of grays to 2 and use GIF89a, that took it down
> to some 17K. But I desperately need to get rid of another 10K or so. Would
> IFS do it (fractals)? Wavelets? I have no experience with those.
> 
> A clue, anyone?
> 
> /Jan A
> 
> jana@tumbleweedtrail.com

The first question I have to ask is why do you need grey colours? If you
use monochrome, you will get an instant 8:1 compression.

Personally I'd recommend TIFF (which is itself a loose rag-bag of
formats). The CCITT (ITU these days) format used for faxes is pretty
good, combining, if I remember rightly, RLE and Huffman coding. It's
also lossless. You don't say what dimension paper you need to use (and I
can't guess as you dont say if you used RLE bmp or not). But for A4
paper, monochrome TIFF should at least get you into the 10K ballpark.

Cheers
Paul
-- 
Paul Floyd	Focal Ingenierie Sud
Mail: paul underscore floyd at focal dot fr
Sig tagline under contemplation.

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

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

From: thannymeister@spambegone.yahoo.com                30-Aug-99 03:39:00
  To: All                                               30-Aug-99 12:22:13
Subj: Re: atoi access exception

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

On Sat, 28 Aug 1999 23:42:35 GMT, Paul Ratcliffe wrote:

>On Sat, 28 Aug 1999 04:14:11 -0400 (EDT), Mike Ruskai
<thannymeister@yahoo.com>
>wrote:
>
>>In fact, it behaves in every way as a pointer.
>
>Really? Well then, in that case perhaps you can tell us all how you change
>this pointer to point to something else?

You don't, because it is a constant pointer.  Are you going to now say that a
constant pointer isn't a pointer?

>>There are very few differences indeed beyond the return value of sizeof().
>
>And the fact that it is an Rvalue. Well, gee, that's 2 already.

Again, is a constant pointer not a pointer?  Is a cat not a feline?

>Anyhow, this is all rather irrelevant to this group. If you want to carry on
>arguing, I suggest you go and do it in comp.lang.c or somewhere.

This is a programming forum, so it's at least partially on topic.


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: karin@btsoftware.com                              30-Aug-99 09:57:27
  To: All                                               30-Aug-99 12:22:13
Subj: HomePage Publisher  !!!!!!!

From: "karin" <karin@btsoftware.com>

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

HomePage Publisher (HPP) is a WYSIWYG Web Page Design tool for 
OS/2.

HPP is an integrated WYSIWYG HTML Publisher and Editor/Browser. 
HomePage is a new product that will allow 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. Select text and objects you want to
change attributes of and make changes by simply clicking toolbars, etc... 
In short, HPP is a Web browser that offers you, as an extra, all the 
possibilities of a word processor. HomePage generates a high quality 
HTML code.

HomePage Publisher Version 2.1 includes Frames support, DBCS, 
Publishing, Drag/Drop, Undo/Redo, Toolbar Designer, Dictionary, and 
more...
  


Check it out and download HomePage Publisher for a free trial period 
from:
	http://www.btsoftware.com/os2/hpp.htm




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

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

From: thannymeister@spambegone.yahoo.com                30-Aug-99 04:16:02
  To: All                                               30-Aug-99 12:22:13
Subj: Re: atoi access exception

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

On Sun, 29 Aug 1999 00:31:41 GMT, Darin McBride wrote:

>[Contemplated adding comp.lang.c just for a few others that would agree with
>me, but decided against a flame war over such a misunderstanding.]
>
>On Sat, 28 Aug 1999 17:17:10 -0400, Marty wrote:
>
>>Darin McBride wrote:
>>> 
>>> >It certainly is bound to an array, which does allow sizeof() to return
the
>>> >array size, as I said in the part of my post you snipped out, but it is
also
>>> >in fact a pointer.  The value of cpTest is the address of the first
element
>>> 
>>> It also, in fact, is *not* a pointer, but an "array type" [ANSI/ISO
9899/1990
>>> 6.1.2.5].
>>> 
>>> What you're saying is akin to saying that a short is a long because you
can
>>> use a short where you can use a long.  The fact that a variable of "array
>>> type" can be cast to "pointer" implicitly no more makes an array a pointer
>>> than the fact that a short can be cast to a long implicitly makes a short
a
>>> long.
>>
>>There's no casting involved.  If you say:
>>char *ptr;
>>ptr = malloc(64);
>>
>>versus:
>>char ptr[64];
>>
>>The only difference is where the storage is allocated from (due to the
>>malloc itself) and what sizeof returns.  I challenge you to prove
>>otherwise.  If you look at the assembly code produced by the compiler, you
>
>Those two differences (moreso sizeof) is what makes it a different type.  I
>don't need to prove anything else.
>
>>would see that it gets accessed in the same way, other than the fact that
>>in the second case it may be located on the stack frame.  In a casting
>>situation, the compiler produces extra assembly code to convert the one
>>type to another.
>
>Take a look at what's on the stack in the two situations.
>
>In the case where you have a char*, the ptr is on the stack, and the memory
>being used for the array is elsewhere.  Stack: 4 bytes (usually), heap: 64
>bytes.  The ptr is at a constant offset from the stack pointer, but the data
>is in a dynamic position in the heap.
>
>In the case where you just have the array, the object (which in this case is
>an array of char) is on the stack directly.  There is no pointer.  It is at a
>constant offset from the stack pointer.  There are no dynamics.

Not necessarily.  If the array is part of a structure, and the structure is
allocated dynamically, the array data will not be on the stack, it will be on
the free store (or heap, whatever term you like).

Where the data is stored is unimporant for these purposes.

Outside of the semantics you'll find in the ANSI reference, the symbol will
be a pointer (a constant one, true enough, but a pointer nonetheless).

Whether declared statically (not to be confused with semantically static
variables), or allocated dynamically, the following holds true:

cpTest /* address of array's first element, no casting done */
cpTest[n] /* equal to *(cpTest+n) */
&cpTest[n] /* equal to cpTest+n */

>>> Sizeof isn't a function.  It's an operator.  And as such, the "return
value"
>>> is a critical difference.
>>
>>It's a precompiler macro.  It doesn't actually exist in your code and is
>
>Nope, try again.  According to 6.3.3.4, it's an operator.  It is defined to
>not work on dynamic types in C++, and there are no dynamic types in C.  Just
>like "2 + 2" results in being compiled to "4" (rather than evaluated at
>runtime), sizeof is compiled to its constant value.  The preprocessor cannot
>do sizeof since the preprocessor doesn't know anything about structures,
>arrays, etc.

This is purely semantics.  The replacement may not be done by the
preprocessor, but the replacement is done before the compiler sets to work. 
sizeof(x) is a constant value by the time an expression it contains is
parsed.  If it weren't, then you'd be unable to declare arrays with the
bounds defined by the result of a sizeo() - which you certainly can do:

#include <stdio.h>

struct foo
{
    int foo1;
    char foo2;
    double foo3;
};

int main()
{
    int foobar[sizeof(struct foo)];
    
    printf("\nsizeof(struct foo)*sizeof(int): %d\n", sizeof(struct
foo)*sizeof(int));
    printf("\nsizeof(foobar): %d\n", sizeof(foobar));
 
    return 0;
}

The above will compile, because sizeof() is actually a constant value. 
Regardless of how you wish to label it semantically, it is a macro in
function.

>>It is special-cased to behave this way.  It is implemented in assembly the
>>way a pointer is implemented.
>
>Then you have a seriously broken compiler.
>
>#ifdef USE_PTR
>char* ptr = malloc(64);
>#else
>char ptr[64];
>#endif
>int i;
>
>fill_ptr_with_random_data(ptr);  /* takes a char* */
>for (i = 0; i < 100; ++i)
>{
>  printf("%d => %d\n", i, 
>         (int)ptr[rand() % 64]);
>}
>
>The assembly looks like (crudely because I don't know x86 assembly, only
>68000) this for loading the right character for the printf.
>
>  load stackpointer
>  add  offset_to_ptr
>#ifdef USE_PTR
>  load this_pointer
>#endif
>  add  i
>  load this_pointer
>
>They are significantly different since the array is already on the stack. 
>Further, your mythical ptr is merely pointing to an array anyway.  An array
>object is a distinctly different object than a pointer object according to
>the standard.

Another example, much simpler, with actual assembly:

#include <stdlib.h>

struct foobar
{
    char foo1[64];
};

int main()
{
    char *foo2, afoo;
    struct foobar* pfoobar;
    int i;

    pfoobar=(struct foobar*)malloc(sizeof(struct foobar));
    foo2=(char*)malloc(sizeof(char)*64);

    for (i=0; i<64; i++)
        {
        afoo=pfoobar->foo1[i];
        afoo=foo2[i];
        }

    return 0;
}

The relevant assembly portions:

; 19         afoo=pfoobar->foo1[i];
        mov     eax,[ebp-04h];  pfoobar
        mov     ecx,[ebp-0ch];  i
        mov     al,byte ptr [eax+ecx]
        mov     [ebp-0dh],al;   afoo

; 20         afoo=foo2[i];
        mov     eax,[ebp-08h];  foo2
        mov     ecx,[ebp-0ch];  i
        mov     al,byte ptr [eax+ecx]
        mov     [ebp-0dh],al;   afoo

As you can see, the assembly is the same for both the explicit array and
dynamic array, because they are both located on the heap.  Only if you
allocate the array on the stack will the behavior of the symbol be different.
 Therefore, it should be clear that the only difference between what the ANSI
specs call an "array" object and a "pointer" object is semantic, outside of
the value of sizeof(), and parameter checking.  And yes, the behavior is as a
constant pointer.


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: kocsisp@dragon.klte.hu                            30-Aug-99 11:11:27
  To: All                                               30-Aug-99 12:22:13
Subj: HLT commands in DOS box

From: Doodle <kocsisp@dragon.klte.hu>

Where could I find any infos about things can be done with HLT commands in
an OS/2 DOS-box?

I've just tried to disassemble the FSFILTER.SYS file, and it does all the
low-level file accesses with HLT commands. Puts datas into registers
(mainly BX), HLT, some DBs, and that's all.
So, are there any infos about them somewhere?

Thanks!
  Doodle

-- Doodle -------------------------------------------------------------------
 PapirPosta: Kocsis Peter, 5363, Nagyiva'n, O~rsi 2/c
-------------------------------------------------------------------- OS/2 ---

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: C3 - Center for Culture and Communication (1:109/42)

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

From: mamodeo@stny.rr.com                               30-Aug-99 14:16:28
  To: All                                               30-Aug-99 16:56:27
Subj: Re: HLT commands in DOS box

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

Doodle wrote:
> 
> Where could I find any infos about things can be done with HLT commands in
> an OS/2 DOS-box?
> 
> I've just tried to disassemble the FSFILTER.SYS file, and it does all the
> low-level file accesses with HLT commands. Puts datas into registers
> (mainly BX), HLT, some DBs, and that's all.
> So, are there any infos about them somewhere?

Cool!  That's how they do it.  I remember just going into Debug and
issuing a HLT command closing the VDM window.  That's a good question,
but I'll bet reverse-engineering may be your only option.

- Marty

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

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

From: steve53_remove_this@earthlink.net                 30-Aug-99 10:10:11
  To: All                                               30-Aug-99 16:56:28
Subj: Re: atoi access exception

From: steve53_remove_this@earthlink.net

In <37C307DA.DEE4A25@stny.rr.com>, on 08/24/99 
   at 05:00 PM, Marty <mamodeo@stny.rr.com> said:

>> char cpTest[64];
>> int iNum;
>> 
>> memset(cpTest,'\0',sizeof(cpTest));

>Incidentally, sizeof(cpTest) = 4.  cpTest is a pointer to a character
>buffer.  I don't believe it's size is 64 as you seem to expect.  Perhaps
>I am mistaken.  It depends on how intelligent the C compiler is I guess.

Rather than guessing, please do at test case:

  printf("%d\n", sizeof(cpTest));

will go far to correcting some of your incorrect assumptions.

Have fun,

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: hubert@ugrad.cs.ualberta.ca                       30-Aug-99 12:28:13
  To: All                                               30-Aug-99 16:56:28
Subj: Re: atoi access exception

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

On Mon, 30 Aug 1999, Mike Ruskai wrote:

> Another example, much simpler, with actual assembly:
> 
> #include <stdlib.h>
> 
> struct foobar
> {
>     char foo1[64];
> };
> 
> int main()
> {
>     char *foo2, afoo;
>     struct foobar* pfoobar;
>     int i;
> 
>     pfoobar=(struct foobar*)malloc(sizeof(struct foobar));
>     foo2=(char*)malloc(sizeof(char)*64);
> 
>     for (i=0; i<64; i++)
>         {
>         afoo=pfoobar->foo1[i];
>         afoo=foo2[i];
>         }
> 
>     return 0;
> }
> 
> The relevant assembly portions:
> 
> ; 19         afoo=pfoobar->foo1[i];
>         mov     eax,[ebp-04h];  pfoobar
>         mov     ecx,[ebp-0ch];  i
>         mov     al,byte ptr [eax+ecx]
>         mov     [ebp-0dh],al;   afoo
> 
> ; 20         afoo=foo2[i];
>         mov     eax,[ebp-08h];  foo2
>         mov     ecx,[ebp-0ch];  i
>         mov     al,byte ptr [eax+ecx]
>         mov     [ebp-0dh],al;   afoo

Actually, it looks like this shows that foo2 and foo1 are different types.
When you do pfoobar->foo1[i], you would be doing 2 dereferences if foo1
were a pointer.  Once dereferencing pfoobar, and once dereferencing
foo1+i.  But here, the compiler only does one.

Try this:
#include <stdlib.h>

struct foobar1
{
    char foo1[64];
};

struct foobar2
{
    char *foo2;
};

int main()
{
    struct foobar1* pfoobar1;
    struct foobar2* pfoobar2;
    int i;

    pfoobar1=(struct foobar1*)malloc(sizeof(struct foobar1));
    pfoobar2=(struct foobar2*)malloc(sizeof(struct foobar2));
    pfoobar2->foo2=(char*)malloc(sizeof(char)*64);

    for (i=0; i<64; i++)
        {
        afoo=pfoobar1->foo1[i];
        afoo=pfoobar2->foo2[i];
        }

    return 0;
}

This is probably a more "fair" comparison, and I'm sure you'll see
different assembly code for 
  afoo=pfoobar1->foo1[i]
and
  afoo=pfoobar2->foo2[i]

BTW, you should be cautious of comparing assembly code to determine
whether things are the "same", or relying on a compiler's behaviour.  For
example, in any 32-bit compiler, and 'int' and a 'long' will be handled
the same, since they are both 32-bit values.  However, they are definitely
not the same.

Hubert.

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

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

From: blaschke@us.ibm.com                               30-Aug-99 14:00:27
  To: All                                               30-Aug-99 16:56:28
Subj: Re: LX file format?

From: Dave Blaschke <blaschke@us.ibm.com>


Will Rose wrote:

> Much to my annoyance I've had to dis-assemble and patch an LX-format DLL.
> I've got most of the format details from Viscuso's book, but I don't
> understand the LX header value 'object iterated pages offset'.  I'd expect
> it to be the offset of the iterated data pages, but it doesn't seem to
> point to something like that in the files I've looked at.
>
> My other problem is that some 32-bit records in the entry name table have
> a flag value of 3, rather than 1 or 0xf8 which are the only two valid
> flags I can find. (f8 is a mask).  What does the second bit do?

In exe386.h, E32EXPORT is defined as 0x01 and E32SHARED is defined as 0x02, so
a 3 would mean the 32-bit entry is exported and uses shared data.  How the
E32SHARED bit is set or its validity is a can of worms I'd rather not open, as
it may be set if there is a shared data segment in the DLL whether the entry
"uses" it or not...

>
>
> Anyone have any answers to these questions, or a place where I could look?
>
> Thanks - Will
> cwr@crash.cts.com



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

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

From: blaschke@us.ibm.com                               30-Aug-99 13:55:07
  To: All                                               30-Aug-99 16:56:28
Subj: Re: LX file format?

From: Dave Blaschke <blaschke@us.ibm.com>


Will Rose wrote:

> Much to my annoyance I've had to dis-assemble and patch an LX-format DLL.
> I've got most of the format details from Viscuso's book, but I don't
> understand the LX header value 'object iterated pages offset'.  I'd expect
> it to be the offset of the iterated data pages, but it doesn't seem to
> point to something like that in the files I've looked at.
>
> My other problem is that some 32-bit records in the entry name table have
> a flag value of 3, rather than 1 or 0xf8 which are the only two valid
> flags I can find. (f8 is a mask).  What does the second bit do?

In exe386.h, E32EXPORT is defined as 0x01 and E32SHARED is definedas 0x02, so
a 3 would mean the entry is exported and uses shared data.  How
the E32SHARED bit is set or its validity is a can of worms I'd rather not
open, it may be set if there is a shared data segment in the DLL whether the
entry "uses" it or not...

>
>
> Anyone have any answers to these questions, or a place where I could look?
>
> Thanks - Will
> cwr@crash.cts.com



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

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

From: cwr@cts.com                                       30-Aug-99 19:38:23
  To: All                                               30-Aug-99 19:58:00
Subj: Re: LX file format?

From: Will Rose <cwr@cts.com>

Dave Blaschke <blaschke@us.ibm.com> wrote:


: Will Rose wrote:

:> Much to my annoyance I've had to dis-assemble and patch an LX-format DLL.
:> I've got most of the format details from Viscuso's book, but I don't
:> understand the LX header value 'object iterated pages offset'.  I'd expect
:> it to be the offset of the iterated data pages, but it doesn't seem to
:> point to something like that in the files I've looked at.
:>
:> My other problem is that some 32-bit records in the entry name table have
:> a flag value of 3, rather than 1 or 0xf8 which are the only two valid
:> flags I can find. (f8 is a mask).  What does the second bit do?

: In exe386.h, E32EXPORT is defined as 0x01 and E32SHARED is definedas 0x02,
so
: a 3 would mean the entry is exported and uses shared data.  How
: the E32SHARED bit is set or its validity is a can of worms I'd rather not
: open, it may be set if there is a shared data segment in the DLL whether the
: entry "uses" it or not...


Thank you thank you thank you.  That was the last outstanding problem with
that piece of code; and I never thought of looking for a header file.  I'll
do some more digging in that area.  I really don't care why the flag is
used - just that it's not a figment of my imagination...

BTW, does anyone know a source for the compression algorithm used in LX
files?  Apparently the linker compresses some iterated data pages _after_
the records have been set up.  I'm not really bothered about it, since
I've got the rest of the LX tables sorted, but it's an interesting
sidelight, and if I could uncompress the data I'd take a look at it.


Will
cwr@crash.cts.com

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

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

From: shaun@primenet.com                                30-Aug-99 19:43:00
  To: All                                               30-Aug-99 19:58:00
Subj: (1/2) Re: How to query if program is running

From: shaun@primenet.com (Shaun Tancheff)

On Mon, 23 Aug 1999 13:38:58 -0500, Wayne Strong <wstrong@spss.com>
wrote:

>Hey,
>
>I've been unable to determing which call to use to determing if a given
>program is currently executing or not.  The identity of the program in
>question would be identified by its pathname.
>
>Any suggestions would  be appreciated.
>
>
>Wayne Strong
>wstrong@spss.com

/*
 * Scan the current process for just a pid, or all the children of
ppid 
 *
 */
INT procQueryPids( u_long * pPids, int maxPids, u_long ulPPid, u_long
ulPid )
{
  INT iPidCount = 0;
  qsPtrRec_t * ProcStatusList;
  ProcStatusList = _PidLookup( ulPid, False ); /* Lookup exact in
Warp4 */
  if ( ProcStatusList )
    {
      qsPrec_t * pProcess;
      if ( ulPid != 0 ) /* Look for: pid */
        {
          /*  In warp4 we only get one record.
           *  In warp3 we get everything.
           */
          for ( pProcess = ProcStatusList -> pProcRec;
                           pProcess -> RecType == 1;
                           pProcess = _psNextProcess( pProcess ) )
            {
  
              if ( pProcess -> pid == ulPid )
                {
                  pPids[iPidCount++] = pProcess -> pid;
                  pPids[iPidCount]   = pProcess -> ppid;
                  pPids[iPidCount+1] = pProcess -> sgid;
                }
            }
        }
      else
        {
          for ( pProcess = ProcStatusList -> pProcRec;
                           pProcess -> RecType == 1;
                           pProcess = _psNextProcess( pProcess ) )
            {
              if ( ulPPid == 0 || pProcess -> ppid == ulPPid )
                {
                  pPids[iPidCount++] = pProcess -> pid;
                }
            }
        }
    }
   /* Cleanup ? */
   /* _PidLookup( 0, True ); */
  return iPidCount;
}

/*
 * Wrapper for DosQuerySysState (32 Bit)
 */
qsPtrRec_t * _PidLookup( ULONG iPid, int boolFreeMemory )
{
  static qsPtrRec_t * ProcStatusList = NULL;
  APIRET rcApi = NO_ERROR;

  if ( boolFreeMemory && iPid == 0 )
    {
      if ( ProcStatusList ) free(ProcStatusList);
      ProcStatusList = NULL;
    }
  else
    {
      if ( ProcStatusList == NULL )
        {
          ProcStatusList = (qsPtrRec_t *)malloc( DosQProcSize );
        }

      if ( ProcStatusList )
        {
#ifdef _WARP4_
          rcApi = DosQuerySysState( QS_QUERY_PROCESS,
                                    RESERVED,
                                    iPid,
                                    RESERVED,
                                    ProcStatusList,
                                    DosQProcSize);

          if ( rcApi != NO_ERROR ) /* Return NULL on error */
            {
              if ( ProcStatusList ) free(ProcStatusList);
              ProcStatusList = NULL;
            }
#else /* 2.1 to _WARP3_ */
          /* Not sure what the 16 bit version returns .. */
          DosQProcStatus( ProcStatusList, DosQProcSize );
          rcApi = NO_ERROR;
#endif 
        }
    }

  return rcApi ? NULL : ProcStatusList;
}

/*
 * Return address of the 'next' process
 *  - this is made difficult due to poor documentation but ...
 *    it appears that the 'last' set of arrays for a process record
entry
 *    will be blocks of contiguous ThreadControlBlocks (TCB) that we
have
 *    a pointer to the start of, and the number of TCBs associated
with this
 *    process. So next_record =
StartOfThreadControlBlocks+Count*SizeOfEachTCB
 */
qsPrec_t * _psNextProcess( qsPrec_t * Record )
{
  char * pNext;

  pNext = (char *) Record -> pThrdRec;
  pNext += Record -> cTCB * sizeof(qsTrec_t);

  return (qsPrec_t *) pNext;
}



/* header */
#ifndef __Dos32QuerySysState_header_
#define __Dos32QuerySysState_header_

/* 
*/
#define FAR

#ifdef __cplusplus
extern "C" {
#endif


/*
--------------------------------------------------------------------------

Global Data Section
___________________

The following C language structure defines the information contained
within the global data section that describes global system
information.

*/

typedef struct qsGrec_s {
        ULONG         cThrds;           /* number of threads in use */
        ULONG         cProcs;           /* proccnt;   */
        ULONG         cModules;         /* modulecnt; */
}qsGrec_t;



/* Process Record structure
 *      Holds all per process information.
 *      ________________________________
 *      |       RecType  (=0x00000001)  |
 *      |-------------------------------|
 *      |       pThrdRec                |----|
 *      |-------------------------------|    |
 *      |       pid                     |    |
 *      |-------------------------------|    |
 *      |       ppid                    |    |
 *      |-------------------------------|    |
 *      |       type                    |    |
 *      |-------------------------------|    |
 *      |       stat                    |    |
 *      |-------------------------------|    |
 *      |       sgid                    |    |
 *      |-------------------------------|    |
 *      |       hMte                    |    |
 *      |-------------------------------|    |
 *      |       cTCB                    |    |
 *      |-------------------------------|    |
 *      |       c16Sem                  |    |
 *      |-------------------------------|    |
 *      |       cLib                    |    |
 *      |-------------------------------|    |
 *      |       cShrMem                 |    |
 *      |-------------------------------|    |
 *      |       p16SemRec               |----|--------|
 *      |-------------------------------|    |        |
 *      |       pLibRec                 |----|--------|------|
 *      |-------------------------------|    |        |      |
 *      |       pShrMemRec              |----|--------|------|----|
 *      |-------------------------------|    |        |      |    |
 *      |       16SemIndx[0]            |<---|--------|      |    |
 *      |          .                    |    |               |    |
 *      |          .                    |    |               |    |
 *      |          .                    |    |               |    |
 *      |       16SemIndx[c16Sem-1]     |    |               |    |
 *      |-------------------------------|    |               |    |
 *      |       hmte[0] (or "name str") |<---|---------------|    |
 *      |          .                    |    |                    |
 *      |          .                    |    |                    |
 *      |          .                    |    |                    |
 *      |       hmte[cLib-1]            |    |                    |
 *      |-------------------------------|    |                    |
 *      |       hshmem[0]               |<---|--------------------|
 *      |          .                    |    |
 *      |          .                    |    |
 *      |          .                    |    |
 *      |       hshmem[cShrMem-1]       |    |
 *      |-------------------------------|    |
 *       * refer to thread rec structure<-----
 */



/*
--------------------------------------------------------------------------
 * 
 * 
 * The pLibRec value points to an array of mte handles that indicate
the
 * DLL modules that are directly referred to by the process (.EXE)
program
 * file module.  The cLib value indicates how many dynamic link
library module
 * handles are in the array.
 * 
 *    The pShrMemRec value points to an array of shared memory handles
that
 * indicate the shared memory segments that are being used by the
process.  The
 * cShrMem value indicates how many shared memory segment handles are
in the
 * array.
 * 
 *    The p16SemRec value points to an array of 16 bit system
semaphore indices
 * that indicate the 16 bit system semaphores that are being used by
the
 * process.  The c16Sem value indicates how many 16 bit system
semaphore indices
 * are in the array.
 * 
 *    The status flag gives an indication of the current status of a
process.
 * 
 * The following list defines the possible values for the status flag:
 * 
 *       0x01 - Doing ExitList Processing
 *       0x02 - Exiting thread 1
 *       0x04 - The whole process is exiting
 *       0x10 - Parent cares about termination
 *       0x20 - Parent did an exec-and-wait
 *       0x40 - Process is dying
 *       0x80 - Process in embryonic state
 * 
 *    The following C language declarations define the information
contained
 * within the system resource summary information record that
describes an OS/2
 * thread:
----------------------------------------------------------------------------
*/

/* Thread Record structure
 *      Holds all per thread information.
 */
typedef struct qsTrec_s {
        ULONG         RecType;        /* Record Type */
                                      /* Thread rectype = 100 */
        USHORT        tid;            /* thread ID */
        USHORT        slot;           /* "unique" thread slot number
*/
        ULONG         sleepid;        /* sleep id thread is sleeping
on */
        ULONG         priority;       /* thread priority */
        ULONG         systime;        /* thread system time */
        ULONG         usertime;       /* thread user time */
        UCHAR         state;          /* thread state */
        UCHAR         pad_char;
        USHORT        pad_short;
} qsTrec_t;


/*
--------------------------------------------------------------------------
**
**       Thread Record Structure
**       ________________________________
**       |       RecType  (=0x00000100)  |----|
**       |-------------------------------|    |
**       |       tid                     |    |
**       |-------------------------------|    |
**       |       slot                    |    |
**       |-------------------------------|    |
**       |       sleepid                 |    |
**       |-------------------------------|    |
**       |       priority                |    |
**       |-------------------------------|    |
**       |       systime                 |    |
**       |-------------------------------|    |
**       |       usertime                |    |
**       |-------------------------------|    |
**       |       state                   |    |
**       |-------------------------------|    |
**                                   <--------|
**  
**  
**  
**     The thread slot number is an internal OS/2 thread identifier.
OS/2
**  must uniquely identify all threads within the system.
**     The state value gives an indication of the current state of a
thread.
**  The following list defines some typical thread state values:
**  
**        1 - Ready to run
**        2 - Blocked
**        5 - Running
**  
**  
**     It is outside the scope of this document to further describe
and explain
**  the various thread state values.
**
-----------------------------------------------------------------------------
*/

/*
** FILE SECTION: 
**
*/
typedef struct {
        USHORT  sfn;
        USHORT  refcnt;
        ULONG   flags;
        ULONG   accmode;
        ULONG   filesize;
        USHORT  volhnd;
        USHORT  attrib;
        USHORT  _reserved_;
} QFDS, *PQFDS;

typedef struct qfile {
        ULONG           rectype;        /* 8 for file */
        struct qfile    *next;
        ULONG           opencnt;
        PQFDS           filedata;
        char            name[1];
} QFILE, *PQFILE;


/*
----------------------------------------------------------------------------
**  16 Bit System Semaphore Section
**  ________________________________
**     The following C language declarations define the information
contained
**  within the system resource summary information record that is the
first
**  record in the 16 bit system semaphore record section of the
DosQProcStatus
**  buffer:
**
--------------------------------------------------------------------------
*/
typedef struct qsS16rec_s {
        ULONG           NextRec;          /* offset to next record in
buffer*/
        UINT            s_SysSemOwner;    /* thread owning this
semaphore   */
        UCHAR           s_SysSemFlag;     /* system semaphore flag bit
field*/
        UCHAR           s_SysSemRefCnt;   /* number of references to
this   */
                                          /*   system semaphore
*/
        UCHAR           s_SysSemProcCnt;  /*number of requests by sem
owner*/
        UCHAR           uchar_Reserved1;
        ULONG           ulong_Reserved2;
        UINT            uint_Reserved3;
        CHAR            SemName;          /* start of semaphore name
string */
} qsS16rec_t;


typedef struct qsS16Headrec_s {
        ULONG         SRecType;          /* semaphore rectype = 3 */
        ULONG         ulong_Reserved1;   /* overlays NextRec of 1st
qsS16rec_t*/
        ULONG         ulong_Reserved2;
        ULONG         S16TblOff;         /* index of first
semaphore,SEE PSTAT OUTPUT*/
                                         /* System Semaphore
Information Section     */
} qsS16Headrec_t;

/*
**    16 bit System Semaphore Header Record Structure
**      ________________________________
**      |       qsS16Headrec            |
**      |-------------------------------|
**      |       qsS16rec_s              |____
**      |_______________________________|    |
**      |                               |<---|
**      |       qsS16rec_s              |----
**      |______________________________ |   |
**      |                               |<--|
**      |       qsS16rec_s              |____
**      |_______________________________|   |
**      |            .                  |<--|
**      |-------------------------------|
**
**
**     The following C language declarations define the 16 bit system
semaphore
**  records:
**  
**  
**        16 bit System Semaphore Record Structure
**      ________________________________
**      |       pNextRec                |----|
**      |-------------------------------|    |
**      |                               |    |
**      |       SysSemOwner             |    |
**      |       SysSemFlag              |    |
**      |       SysSemRecCnt            |    |
**      |       SysSemProcCnt           |    |
**      |                               |    |
**      |-------------------------------|    |
**      |SemName:                       |    |
**      |       "pathname"              |    |
**      |-------------------------------|    |
**                                      <-----
**
**
**

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

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

From: shaun@primenet.com                                30-Aug-99 19:43:00
  To: All                                               30-Aug-99 19:58:00
Subj: (2/2) Re: How to query if program is running

** The s_SysSemOwner is the slot ID of the semaphore's owner
** 
** The s_SysSemFlag is the system semaphore flag bit field which
describes
** the type or action the semaphore is performing.
** 
** The s_SysSemRecCnt is the number of references to a specific
semaphore.
** 
** The SemName value is actually the first byte of an ASCIIZ string
that is
** the complete pathname of the 16 bit system semaphore.
** 
**
**
** 
** Executable Module Section
** ___________________________
** The following C language declarations define the information
contained
** within the system resource summary information record that
describes an OS/2
** DLL module:
**
--------------------------------------------------------------------------
*/

typedef struct qsLrec_s {
        void  FAR       *pNextRec;    /* pointer to next record in
buffer */
        USHORT        hmte;           /* handle for this mte */
        USHORT        Reserved;       /* Reserved */
        ULONG         ctImpMod;       /* # of imported modules in
table */
        ULONG         ulong_Reserved1;        /* Reserved */
/*    (*** qsLObjrec_t FAR) */ ULONG * pUGLY_Reserved2;    /* Reserved
*/
        UCHAR     FAR *pName;         /* ptr to name string following
stru*/
} qsLrec_t;


/*
**      System wide MTE information
**      ________________________________
**      |       pNextRec                |----|
**      |-------------------------------|    |
**      |       hmte                    |    |
**      |-------------------------------|    |
**      |       ctImpMod                |    |
**      |-------------------------------|    |
**      |       Reserved                |    |
**      |-------------------------------|    |
**      |       Reserved                |    |
**      |-------------------------------|    |
**      |       pName                   |----|----|
**      |-------------------------------|    |    |
**      |       imported module handles |    |    |
**      |          .                    |    |    |
**      |          .                    |    |    |
**      |          .                    |    |    |
**      |-------------------------------| <--|----|
**      |       "pathname"              |    |
**      |_______________________________|    |
**                                      <-----
**
**
**-----------------------------------------------------------------------------

**    The hmte value is a unique identifier that identifies this DLL
** module.
** 
**    The ctImpMod value indicates how many other DLL's this module
statically
** references.  The ctImpMod value does not take into account any
DLL's that
** were dynamically linked at run time.
** 
**    The pName value is a 16 bit pointer that points to an ASCIIZ
string that
** follows the DLL module record.  The string contains the pathname of
the DLL
** module.
**  
**
-----------------------------------------------------------------------------
**  Shared Memory Segment Section
**  ______________________________
**  The following C language declarations define the information
contained
**  within the system resource summary information record that
describes an OS/2
**  shared memory segment:
**
-----------------------------------------------------------------------------

*/

typedef struct qsMrec_s {
        ULONG         MemNextRec;       /* offset to next record in
buffer */
        USHORT        hmem;             /* handle for shared memory */
        USHORT        sel;              /* shared memory selector */
        USHORT        refcnt;           /* reference count */
        CHAR          Memname;          /* start of shared memory name
string */
} qsMrec_t;

/* --- Shared Mem Record Structure
------------------------------------------
**     ________________________________
**     |       MemNextRec              |----|
**     |-------------------------------|    |
**     |       hmem                    |    |
**     |-------------------------------|    |
**     |       sel                     |    |
**     |-------------------------------|    |
**     |       refcnt                  |    |
**     |-------------------------------|    |
**     |       Memname                 |    |
**     |_______________________________|    |
**                                     <-----
** 
** Like the 16 bit system semaphore record, the shared memory segment
record
** contains its full ASCIIZ string pathname at the end of the record.
**
**
**
--------------------------------------------------------------------------
**  
**  Process and Thread Data Section
**  _______________________________
**  The following C language declarations define the information
contained
**  within the system resource summary information record that
describes an OS/2
**  process.  Each process record is immediately followed by one or
more thread
**  records for the given process.   The pointer qsTrec_t points to
the first
**  thread record structure for the process.
*/

typedef struct qsPrec_s {
        ULONG         RecType;        /* type of record being
processed */
                                      /* process rectype = 1
*/
        qsTrec_t FAR *pThrdRec;    /* ptr to 1st thread rec for this
prc*/
        USHORT        pid;            /* process ID */
        USHORT        ppid;           /* parent process ID */
        ULONG         type;           /* process type */
        ULONG         stat;           /* process status */
        ULONG         sgid;           /* process screen group --
Session ID. */
        USHORT        hMte;           /* program module handle for
process */
        USHORT        cTCB;           /* # of TCBs in use in process
*/
        ULONG         cPrivSem32;     /* Priv[ate|alaged] Sem32's
count */
        ULONG * /*void*/ FAR pvoid_Reserved2;
        USHORT        c16Sem;         /*# of 16 bit system sems in use
by proc*/
        USHORT        cLib;           /* number of runtime linked
libraries */
        USHORT        cShrMem;        /* number of shared memory
handles */
        USHORT        cFileDS;        /* number of files/descriptor
[open?] */
        USHORT  FAR   *p16SemRec;     /*ptr to head of 16 bit sem inf
for proc*/
        USHORT  FAR   *pLibRec;       /*ptr to list of runtime lib in
use by  */
                                      /*process*/
        USHORT  FAR   *pShrMemRec;    /*ptr to list of shared mem
handles in  */
                                      /*use by process*/
        USHORT  FAR   *pFileDsRec;    /* Pointer to what cFileDS
counts */
} qsPrec_t;


/*
--------------------------------------------------------------------------

Pointer Record Section
_______________________

The following pointer record structure is the first section in the
buffer.
It contains pointers to the heads of the system resource information
sections.

--------------------------------------------------------------------------
*/

typedef struct qsPtrRec_s {
        qsGrec_t        *pGlobalRec;    /* ptr to the global data
section */
        qsPrec_t        *pProcRec;      /* ptr to process record
section  */
        qsS16Headrec_t  *p16SemRec;     /* ptr to 16 bit sem section
*/
        qsMrec_t        *pShrMemRec;    /* ptr to shared mem section
*/
        qsLrec_t        *pLibRec;       /*ptr to exe module record
section*/
} qsPtrRec_t;



#define RESERVED                0x00

#define QS_RECTYPE_PROCESS      0x0001
#define QS_RECTYPE_SEMAPHORE    0x0003
#define QS_RECTYPE_THREAD       0x0100  /* 256 decimal */

/* Func for DosQuerySysState */
#define QS_QUERY_PROCESS        0x01
#define QS_QUERY_SEMAPHORE      0x02
#define QS_QUERY_MODULE         0x04
#define QS_QUERY_FILE           0x08
#define QS_QUERY_SHAR_MEM       0x10
#define QS_QUERY_OTHER          0x20    /* Undefined? */


/* Function Prototypes */
/* int DosQProcStatus( qsPtrRec_t *, int ); */
/* DosQProcStatus() = DOSCALLS.154 */
USHORT APIENTRY16 DosQProcStatus(PVOID pBuf, USHORT cbBuf);

/* DosQuerySysState = DOSCALLS.368 */
APIRET APIENTRY   DosQuerySysState(ULONG func, ULONG par1, ULONG pid, 
                                   ULONG _reserved_, PVOID buf, ULONG
bufsz);

/*
-----------------------------------------------------------------------
**  rc = Dos32QuerySysState(
**               ULONG func,     -- pushed last 
**               ULONG arg1,
**               ULONG pid,
**               ULONG _res_,
**               PVOID buf,
**               ULONG bufsz);   -- pushed first
**  
**  Note it is: 
**  
**       Dos[16]QprocStatus((16:16)buf,bufsz) == 
**       Dos[32]QuerySysState(0x17,0,0,0,(0:32)buf,bufsz);
**  
**  Arguments
**  
**  bufsz (ULONG) 
**       length of buffer passed 
**  buf (PVOID) 
**       buffer for returning data 
**  _res_ (ULONG) 
**       _reserved_, not used currently 
**  pid (ULONG) 
**       see note 1 
**  arg1 (ULONG) 
**       see note 3 
**  func (ULONG) 
**       function code 
**            00000001 process data 
**            00000002 semaphore data 
**            00000004 module data 
**            00000008 file data (see note 2) 
**            00000010 named shared memory data 
*/

#ifdef __cplusplus
}
#endif

#endif /* __Dos32QuerySysState_header_ */




 http://shaun.tancheff.com/       /?/                 -_-
  :-) shaun ;-] shaun@tancheff.com (Shaun Tancheff) .sigs freed

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

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

From: seg@NOSPAM-us.ibm.com                             30-Aug-99 16:18:19
  To: All                                               30-Aug-99 21:34:14
Subj: Re: HLT commands in DOS box

From: "Scott E. Garfinkle" <seg@NOSPAM-us.ibm.com>

On Mon, 30 Aug 1999 11:11:55 -0100, Doodle wrote:

>I've just tried to disassemble the FSFILTER.SYS file, and it does all the
>low-level file accesses with HLT commands. Puts datas into registers
>(mainly BX), HLT, some DBs, and that's all.
>So, are there any infos about them somewhere?
You would have to be insane to use this, even if you successfully unassemble
it. Use the INTxx functions that are supported. Doing anything else is a huge
invitation to having an app that will mysteriously stop working after
applying a fixpack.


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

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

From: jana.persson@telia.com                            30-Aug-99 23:34:03
  To: All                                               31-Aug-99 03:52:24
Subj: SV: Image compression?

From: "Jan A" <jana.persson@telia.com>

Paul FLOYD <paul_floyd@see.sig> skrev i
diskussionsgruppsmeddelandet:37CA41C9.F66DFD91@see.sig...
> The first question I have to ask is why do you need grey colours? If you
> use monochrome, you will get an instant 8:1 compression.
>
> Personally I'd recommend TIFF (which is itself a loose rag-bag of
> formats). The CCITT (ITU these days) format used for faxes is pretty
> good, combining, if I remember rightly, RLE and Huffman coding. It's
> also lossless. You don't say what dimension paper you need to use (and I
> can't guess as you dont say if you used RLE bmp or not). But for A4
> paper, monochrome TIFF should at least get you into the 10K ballpark.
>
> Cheers
> Paul
> --
> Paul Floyd Focal Ingenierie Sud
> Mail: paul underscore floyd at focal dot fr
> Sig tagline under contemplation.


Thanks Paul! A greyscale image, that's what I have to work with, not my
choice. My task is to shrink it as much as human knowledge permits. The only
criteria is it has to be readable after printout. You're right monochrome (1
bit per pixel) gives me about 7/8 compression. I used that and then
compressed with GIF89a, which took it down to 17K. The dimension of the
paper is about 130x200 mm. Far as I know, the TIFF standard allows for the
use of a number of different compression schemes, the most common is LZW,
which I think is the same one used in the GIF format. I found a format
called CPC at a company called Cartesian Inc. It actually does the job down
to 6K but is only available for Unix and Windows. The have an SDK available
and I guess I could ask them if they plan on making it available for OS/2.
Maybe they're susceptible to a bribe?

/Jan A


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

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

From: eolson@express.ca                                 31-Aug-99 02:16:14
  To: All                                               31-Aug-99 05:26:03
Subj: Re: Image compression?

From: eolson@express.ca (Eric Olson)

On Fri, 27 Aug 1999 22:47:08, "Jan A" <jana.persson@telia.com> wrote:

> Anyone know of any REALLY efficient image compression utility? The type
> image I need compressed is a 200 dpi/256 grays with mostly printed text and
> lines on it. In the BMP format, the image is just above 1 MB in size and I
> need it to be under 10K. Lossy compression OK but have to be able to read
> handwritten text after decompression and printout.
> 
> The amount of grays is actually mostly noise, so the closest I've come this
> far was to reduce the amount of grays to 2 and use GIF89a, that took it down
> to some 17K. But I desperately need to get rid of another 10K or so. Would
> IFS do it (fractals)? Wavelets? I have no experience with those.
> 
> A clue, anyone?

Hello Jan,

 I don't have any experience with it but you could check out 
the free source of the djvu format from at&t and port it to
OS/2. It is based on multiple compression techniques among
which wavelets.

http://djvu.research.att.com/open/

Good luck.

Eric

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

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

From: mamodeo@stny.rr.com                               31-Aug-99 00:45:15
  To: All                                               31-Aug-99 11:04:19
Subj: Is anything wrong with this PM code??

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

I've been plagued with a really strange problem lately and I'm running out
of ideas.  The code below works perfectly fine on <any> non-GRADD video
drivers.  On GRADD video drivers, it either doesn't display anything or
causes a SYS3175 in PMMERGE.DLL.  Can anyone see a problem with this code
-- specifically, something that would cause it to not work depending on the
video driver?  Did I make any assumptions that I shouldn't have?  I
appreciate any and all help.

- Marty

-------------
[window procedure function declaration here]

	static HPS hps2=0;
	static HBITMAP bmp=0, bmp2=0, bmp3=0, bmp4=0;
	static HDC hdc;
	static SWP swp;
	static RECTL winrect;
	static int sequence;
	static int sequence2;
	static int offsetx, offsetx2, offsetx3, offsety;
	HPS hps;
	POINTL pts[3];
	RECTL rect;

	switch (message) {
		case WM_CREATE: {
			BITMAPINFOHEADER bmpinf;
			DEVOPENSTRUC dop = { 0, "DISPLAY", NULL, 0, 0, 0, 0, 0, 0 };
			BITMAPINFO2 bmpi;
			SIZEL size = { 0, 0 };

			hdc = DevOpenDC( WinQueryAnchorBlock( win ), OD_MEMORY, "*", 5,
(PDEVOPENDATA)&dop, NULLHANDLE );
			hps2 = GpiCreatePS( WinQueryAnchorBlock( win ), hdc, &size, PU_PELS |
GPIA_ASSOC );

			WinQueryWindowPos( win, &swp );
			winrect.xLeft = winrect.yBottom = 0;
			winrect.xRight = swp.cx;
			winrect.yTop = swp.cy;

			bmpi.cbFix = sizeof(BITMAPINFO2);
			bmpi.cx = swp.cx;
			bmpi.cy = swp.cy;
			bmpi.cPlanes = 1;
			bmpi.cBitCount = 8;
			bmp = GpiCreateBitmap( hps2, (PBITMAPINFOHEADER2)&bmpi, 0, 0, NULL );

			GpiSetBitmap( hps2, bmp );
			bmp2 = GpiLoadBitmap( hps2, NULLHANDLE, 2, 0, 0 );
			bmp3 = GpiLoadBitmap( hps2, NULLHANDLE, 3, 0, 0 );
			bmp4 = GpiLoadBitmap( hps2, NULLHANDLE, 4, 0, 0 );

			bmpinf.cbFix = sizeof( BITMAPINFOHEADER );
			GpiQueryBitmapParameters( bmp2, &bmpinf );
			offsetx =  (swp.cx >> 1)-(bmpinf.cx >> 1);
			offsety =  0;
			bmpinf.cbFix = sizeof( BITMAPINFOHEADER );
			GpiQueryBitmapParameters( bmp3, &bmpinf );
			offsetx2 = (swp.cx >> 1)-(bmpinf.cx >> 1);
			bmpinf.cbFix = sizeof( BITMAPINFOHEADER );
			GpiQueryBitmapParameters( bmp4, &bmpinf );
			offsetx3 = (swp.cx >> 1)-(bmpinf.cx >> 1);

			GpiSetColor( hps2, CLR_BLACK );
			GpiSetBackColor( hps2, CLR_BLACK );

			sequence = 0; sequence2 = 0;
			WinStartTimer( WinQueryAnchorBlock(win), win, 0, 50 );
		}
		break;
		case WM_PAINT:
			pts[0].x = 0; pts[0].y = 0;
			pts[1].x = swp.cx;  pts[1].y = swp.cy;
			pts[2].x = 0; pts[2].y = 0;

	                hps = WinBeginPaint( win, NULLHANDLE, NULL );
			if ( hps && hps2 ) GpiBitBlt( hps, hps2, 3, pts, ROP_SRCCOPY, BBO_IGNORE
);
			WinEndPaint( hps );
		break;
		case WM_TIMER:
			switch (sequence2) {
				case 0:
					pts[0].x = 0; pts[0].y = 0;
					pts[1].x = swp.cx;  pts[1].y = swp.cy;
					rect.xLeft = swp.cx - sequence;
					rect.xRight = swp.cx;
					rect.yBottom = offsety;
					rect.yTop = swp.cy;
					GpiMove(hps2, &pts[0] );
					GpiBox(hps2, DRO_OUTLINEFILL, &(pts[1]), 0, 0);
					GpiMove(hps2, &pts[0] );
					WinDrawBitmap( hps2, bmp2, NULL, (PPOINTL)&rect, 0, 0,
					    DBM_STRETCH );
					sequence+=10;

					WinInvalidateRect( win, NULL, TRUE );

					if ( sequence > swp.cx-offsetx ) {
							sequence2++;
							sequence = 0;
					}
					break;
				case 1:
					...

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

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

From: jasper_de_keijzer@nl.compuware.com                31-Aug-99 09:35:17
  To: glen@rockyhorror.Zkaroo.co.uk                     31-Aug-99 11:04:19
Subj: Re: File Dialog list box

To: Glen D <glen@rockyhorror.Zkaroo.co.uk>
From: Jasper de Keijzer <jasper_de_keijzer@nl.compuware.com>

Glen,

If you realy don't wanna write the code yourself than you should have a
look for the gbmsrc.zip (generic bitmap sources) on hobbes. On of the
source files subclasses the filedialog. You can simply cut/paste this
into your sources.

regards,
Jasper de Keijzer
http://home-5.worldonline.nl/~jdekeij


Glen D wrote:
> 
> I'm making a program that creates a dialog box that asks the user to
> choose a directory.  I'd like to use the listbox you see in the bottom
> left of the OS/2 File dialog box under "Directory:" (this is on Warp
> 3).  Is there any way of extracting this?  I'd prefer not to have to
> write the code myself.
> 
> Thanks in advance,
> 
> Glen D
> -<remove Z from my e-mail address>-

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

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

From: jasper_de_keijzer@nl.compuware.com                31-Aug-99 09:40:00
  To: "jwise"@hal-pc.org@hal-pc.org                     31-Aug-99 11:04:19
Subj: Re: POWER GUI BY LEONG, Et Al

To: Jack Wise <"jwise"@hal-pc.org@hal-pc.org>
From: Jasper de Keijzer <jasper_de_keijzer@nl.compuware.com>

Jack,

I can send you the contents of the diskette by ftp if you want.
Let me know.

regards
Jasper de Keijzer
http://home-5.worldonline.nl/~jdekeij

Jack Wise wrote:
> 
> I need the updated/corrected program files for this book.
> 
> I had downloaded them but never installed.  Now I can't find the
> diskette.
> 
> Anyone know the URL/ftp address for the download?
> 
> Thanks
> 
> Jack Wise
> 
> jwise@hal-pc.org

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

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

From: jasper_de_keijzer@nl.compuware.com                31-Aug-99 09:40:14
  To: All                                               31-Aug-99 11:04:19
Subj: Re: POWER GUI BY LEONG, Et Al

From: Jasper de Keijzer <jasper_de_keijzer@nl.compuware.com>

Jack,

I can send you the contents of the diskette by ftp if you want.
Let me know.

regards
Jasper de Keijzer
http://home-5.worldonline.nl/~jdekeij

Jack Wise wrote:
> 
> I need the updated/corrected program files for this book.
> 
> I had downloaded them but never installed.  Now I can't find the
> diskette.
> 
> Anyone know the URL/ftp address for the download?
> 
> Thanks
> 
> Jack Wise
> 
> jwise@hal-pc.org

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

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

From: jasper_de_keijzer@nl.compuware.com                31-Aug-99 09:31:17
  To: mamodeo@stny.rr.com                               31-Aug-99 11:04:19
Subj: Re: Is anything wrong with this PM code??

To: Marty <mamodeo@stny.rr.com>
From: Jasper de Keijzer <jasper_de_keijzer@nl.compuware.com>

Marty,

One of the things I encounter in your code is the fact that you do not
initialize the BITMAPINFOHEADER and the BITMAPINFO2 structs to zero
memset((void *)&bmpinf,0,sizeof(BITMAPINFOHEADER)). I've had exactly the
same problem and this fixed it for me.

Regards,
Jasper de Keijzer.
http://home-5.worldonline.nl/~jdekeij


Marty wrote:
> 
> I've been plagued with a really strange problem lately and I'm running out
> of ideas.  The code below works perfectly fine on <any> non-GRADD video
> drivers.  On GRADD video drivers, it either doesn't display anything or
> causes a SYS3175 in PMMERGE.DLL.  Can anyone see a problem with this code
> -- specifically, something that would cause it to not work depending on the
> video driver?  Did I make any assumptions that I shouldn't have?  I
> appreciate any and all help.
> 
> - Marty
> 
> -------------
> [window procedure function declaration here]
> 
>         static HPS hps2=0;
>         static HBITMAP bmp=0, bmp2=0, bmp3=0, bmp4=0;
>         static HDC hdc;
>         static SWP swp;
>         static RECTL winrect;
>         static int sequence;
>         static int sequence2;
>         static int offsetx, offsetx2, offsetx3, offsety;
>         HPS hps;
>         POINTL pts[3];
>         RECTL rect;
> 
>         switch (message) {
>                 case WM_CREATE: {
>                         BITMAPINFOHEADER bmpinf;
>                         DEVOPENSTRUC dop = { 0, "DISPLAY", NULL, 0, 0, 0, 0, 
0, 0 };
>                         BITMAPINFO2 bmpi;
>                         SIZEL size = { 0, 0 };
> 
>                         hdc = DevOpenDC( WinQueryAnchorBlock( win ),
OD_MEMORY, "*", 5,
> (PDEVOPENDATA)&dop, NULLHANDLE );
>                         hps2 = GpiCreatePS( WinQueryAnchorBlock( win ), hdc, 
&size, PU_PELS |
> GPIA_ASSOC );
> 
>                         WinQueryWindowPos( win, &swp );
>                         winrect.xLeft = winrect.yBottom = 0;
>                         winrect.xRight = swp.cx;
>                         winrect.yTop = swp.cy;
> 
>                         bmpi.cbFix = sizeof(BITMAPINFO2);
>                         bmpi.cx = swp.cx;
>                         bmpi.cy = swp.cy;
>                         bmpi.cPlanes = 1;
>                         bmpi.cBitCount = 8;
>                         bmp = GpiCreateBitmap( hps2,
(PBITMAPINFOHEADER2)&bmpi, 0, 0, NULL );
> 
>                         GpiSetBitmap( hps2, bmp );
>                         bmp2 = GpiLoadBitmap( hps2, NULLHANDLE, 2, 0, 0 );
>                         bmp3 = GpiLoadBitmap( hps2, NULLHANDLE, 3, 0, 0 );
>                         bmp4 = GpiLoadBitmap( hps2, NULLHANDLE, 4, 0, 0 );
> 
>                         bmpinf.cbFix = sizeof( BITMAPINFOHEADER );
>                         GpiQueryBitmapParameters( bmp2, &bmpinf );
>                         offsetx =  (swp.cx >> 1)-(bmpinf.cx >> 1);
>                         offsety =  0;
>                         bmpinf.cbFix = sizeof( BITMAPINFOHEADER );
>                         GpiQueryBitmapParameters( bmp3, &bmpinf );
>                         offsetx2 = (swp.cx >> 1)-(bmpinf.cx >> 1);
>                         bmpinf.cbFix = sizeof( BITMAPINFOHEADER );
>                         GpiQueryBitmapParameters( bmp4, &bmpinf );
>                         offsetx3 = (swp.cx >> 1)-(bmpinf.cx >> 1);
> 
>                         GpiSetColor( hps2, CLR_BLACK );
>                         GpiSetBackColor( hps2, CLR_BLACK );
> 
>                         sequence = 0; sequence2 = 0;
>                         WinStartTimer( WinQueryAnchorBlock(win), win, 0, 50
);
>                 }
>                 break;
>                 case WM_PAINT:
>                         pts[0].x = 0; pts[0].y = 0;
>                         pts[1].x = swp.cx;  pts[1].y = swp.cy;
>                         pts[2].x = 0; pts[2].y = 0;
> 
>                         hps = WinBeginPaint( win, NULLHANDLE, NULL );
>                         if ( hps && hps2 ) GpiBitBlt( hps, hps2, 3, pts,
ROP_SRCCOPY, BBO_IGNORE
> );
>                         WinEndPaint( hps );
>                 break;
>                 case WM_TIMER:
>                         switch (sequence2) {
>                                 case 0:
>                                         pts[0].x = 0; pts[0].y = 0;
>                                         pts[1].x = swp.cx;  pts[1].y =
swp.cy;
>                                         rect.xLeft = swp.cx - sequence;
>                                         rect.xRight = swp.cx;
>                                         rect.yBottom = offsety;
>                                         rect.yTop = swp.cy;
>                                         GpiMove(hps2, &pts[0] );
>                                         GpiBox(hps2, DRO_OUTLINEFILL,
&(pts[1]), 0, 0);
>                                         GpiMove(hps2, &pts[0] );
>                                         WinDrawBitmap( hps2, bmp2, NULL,
(PPOINTL)&rect, 0, 0,
>                                             DBM_STRETCH );
>                                         sequence+=10;
> 
>                                         WinInvalidateRect( win, NULL, TRUE
);
> 
>                                         if ( sequence > swp.cx-offsetx ) {
>                                                         sequence2++;
>                                                         sequence = 0;
>                                         }
>                                         break;
>                                 case 1:
>                                         ...

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

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

From: kocsisp@dragon.klte.hu                            31-Aug-99 11:34:21
  To: All                                               31-Aug-99 14:56:01
Subj: Re: HLT commands in DOS box

From: Doodle <kocsisp@dragon.klte.hu>

On Mon, 30 Aug 1999, Scott E. Garfinkle wrote:

> On Mon, 30 Aug 1999 11:11:55 -0100, Doodle wrote:
> 
> >I've just tried to disassemble the FSFILTER.SYS file, and it does all the
> >low-level file accesses with HLT commands. Puts datas into registers
> >(mainly BX), HLT, some DBs, and that's all.
> >So, are there any infos about them somewhere?
>
> You would have to be insane to use this, even if you successfully unassemble
> it. Use the INTxx functions that are supported. Doing anything else is a
huge
> invitation to having an app that will mysteriously stop working after
> applying a fixpack.

Ok, but long filenames cannot be accessed using INTxx functions..:(
(But as I've tried it yesterday, long filenames cannot be accessed with
these HLT commands too.. It converts them to short ones.)

So, as I can see, the only way to access long filenames in a DOS box is to
use a "file server" program. :(

Thanks!
  Doodle

-- Doodle -------------------------------------------------------------------
 PapirPosta: Kocsis Peter, 5363, Nagyiva'n, O~rsi 2/c
-------------------------------------------------------------------- OS/2 ---

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: C3 - Center for Culture and Communication (1:109/42)

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

From: stantowianski@home.com                            31-Aug-99 11:53:24
  To: All                                               31-Aug-99 14:56:01
Subj: Re: Pipes( > < | )  do text only?

From: Stan Towianski <stantowianski@home.com>

I am using IBM's C/C++ 2.01 (?) compiler.  I am writing in C.
These are all my fopen stmt.s:
            else if ( ( out = fopen( newname, "rb") ) != NULL )
        else if ( ( out = fopen( newname, "rb") ) != NULL )
        if ( ( out = fopen( newname, "ab") ) == NULL )
        if ( ( out = fopen( newname, "wb") ) == NULL )
            else if ( ( in = fopen( newname, "rb") ) == NULL )
        else if ( ( in = fopen( newname, "rb") ) == NULL )

It looks to me like OS/2's >  <  and |  are automatically changing LF
to CRLF and vice-versa which it sounds like means they are opening files
in text mode.

Paul Ratcliffe wrote:

> On Sat, 28 Aug 1999 18:14:44 GMT, Stan Towianski <stantowianski@home.com>
> wrote:
>
> >I wrote a cat.exe which write out a file's contents in binary.
> >I think the program is working, but when I redirect is with
> >| or > I think these are only allowing text mode file operations!
>
> You are opening the file in text mode by the sound of it, when you really
> want binary mode. How you select this is dependant on language/compiler and
> you don't say which you are using.....

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

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

From: putmanh@my-deja.com                               31-Aug-99 12:36:13
  To: All                                               31-Aug-99 14:56:01
Subj: Web Explorer Toolkit

From: putmanh@my-deja.com

I am looking for a way to show web pages in an arbitrary window in my
application running under OS/2. I remember a while back there was a
WebExplorer toolkit that let you do this. It seems to have disappeared.
Does anyone have a copy of this or know where I can get it. I know the
HTML support is not up tyo today's standards, but I'm willing to live
with that.

Is there any other way to do this? [I've looked at Gecko from the
Mozilla project but it doesn't seem like it is near complete enough in
Os/2, and I couldn't find any documentation about how you use it in
your own application.]

Thanks for any help or information.

Harold Putman


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: mamodeo@stny.rr.com                               31-Aug-99 09:33:05
  To: All                                               31-Aug-99 14:56:01
Subj: Re: Is anything wrong with this PM code??

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

Jasper de Keijzer wrote:
> 
> Marty,
> 
> One of the things I encounter in your code is the fact that you do not
> initialize the BITMAPINFOHEADER and the BITMAPINFO2 structs to zero
> memset((void *)&bmpinf,0,sizeof(BITMAPINFOHEADER)). I've had exactly the
> same problem and this fixed it for me.

Thanks for the reply.  The only thing that bugs me with that explanation
is that I never had it doing bitmaps before.  If you replace the bitmap
stuff with WinDrawText, the some problem occurs.  I'll give your
suggestion a try when I get home tonight anyway.  Thanks for the input.

- Marty

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

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

From: bigbadal@my-deja.com                              31-Aug-99 13:39:00
  To: All                                               31-Aug-99 14:56:01
Subj: Multiple PCI Device Driver Problem

From: bigbadal@my-deja.com

I am looking to extend a PCI card device driver to handle multiple
cards. The problem is, the PCI driver emulates the legacy interface of
an older ISA card, allowing us to change driver and hardware without
changing any of the host DLLs. To add 2 ISA cards, 2 device drivers
were build and installed. Not elegant, but it worked.

However, using this approach with 2 PCI cards fails. Although the
correct PCI config info, register locations etc are found for each
card, neither driver responds to an IRQ. They are sharing the same IRQ
(declared as RS_IRQ_SHARED etc..), but neither of the service routines
execute during an interrupt. Removing one of the cards and driver -
everything works correctly.

I know the cards are generating interrupts as they work with the NT
device driver on the same box.

Any help would be gratefully accepted,

Alastair


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: seg@NOSPAM-us.ibm.com                             31-Aug-99 09:21:04
  To: All                                               31-Aug-99 14:56:02
Subj: Re: HLT commands in DOS box

From: "Scott E. Garfinkle" <seg@NOSPAM-us.ibm.com>

On Tue, 31 Aug 1999 11:34:42 -0100, Doodle wrote:

>So, as I can see, the only way to access long filenames in a DOS box is to
>use a "file server" program. :(
That is true and there is no way whatsoever to circumvent this inside a  VDM,
with or without undocumentd hacks.


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

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

From: charette@writeme.com                              31-Aug-99 14:53:19
  To: All                                               31-Aug-99 14:56:02
Subj: Re: Pipes( > < | )  do text only?

From: charette@writeme.com

In <37CBC258.D9797845@home.com>, Stan Towianski <stantowianski@home.com>
writes:
>I am using IBM's C/C++ 2.01 (?) compiler.  I am writing in C.
>These are all my fopen stmt.s:

[cut]

You are setting stdout to binary mode as well, right?

Here is a code snippet from some old app I wrote many years ago:

   /* get the filehandle to stdout */
   int filehandle = _fileno( stdout );
   /* force stdout to display using binary instead of text */
   _setmode( filehandle, O_BINARY );

Stephane Charette
charette@writeme.com

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

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

From: fonz@gmx.at                                       31-Aug-99 16:20:25
  To: All                                               31-Aug-99 14:56:02
Subj: Re: Web Explorer Toolkit

From: fonz@gmx.at

On Tue, 31 Aug 1999 12:36:26, putmanh@my-deja.com wrote:

> I am looking for a way to show web pages in an arbitrary window in my
> application running under OS/2. I remember a while back there was a
> WebExplorer toolkit that let you do this. It seems to have disappeared.
> Does anyone have a copy of this or know where I can get it. I know the
> HTML support is not up tyo today's standards, but I'm willing to live
> with that.
 

it was hard to find webex, but here it is:
http://www.networking.ibm.com/WebExplorer/webhome.htm
(you only need webexwin.dll and webexurl.dll)

i can't remember if the api-doku is included
(i have found it somewhere at hobbes, look for webex)


fonz

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

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

From: bvermo@powertech.no                               31-Aug-99 17:32:00
  To: All                                               31-Aug-99 16:34:24
Subj: Re: Pipes( > < | ) do text only?

From: bv <bvermo@powertech.no>

Stan Towianski wrote:

> I am using IBM's C/C++ 2.01 (?) compiler.  I am writing in C.
> These are all my fopen stmt.s:
>             else if ( ( out = fopen( newname, "rb") ) != NULL )
>

... etc

> It looks to me like OS/2's >  <  and |  are automatically changing LF
> to CRLF and vice-versa which it sounds like means they are opening files
> in text mode.

The command line redirection in OS/2 is not designed for any heavy use, as far 
as
I recall.
In any case, the OS/2 command shell is not supposed to be compatible with any
UNIX shell.

This is a very inefficient method for interprogram communication in a
multithreaded operating system, and there are much better mechanisms available 
in
the OS/2 API. You can use named or unnamed pipes, message queues or other IPC
mechanisms.

This goes for file handling, too. Generally, it is both safer and better to
use
the OS/2 APIs for OS/2 programs instead of the general purpose POSIX/c library
ones.

This leads to a different recommended programming style from what is common in
the UNIX world. An added advantage is that the code is easier to read for
other
people. For instance, from the reference in the Developer Toolkit:

 This example opens or creates and opens a normal file named "DOSTEST.DAT",
 writes to it, reads from it, and finally closes it.

 #define INCL_DOSFILEMGR          /* File Manager values */
 #define INCL_DOSERRORS           /* DOS Error values    */
 #include <os2.h>
 #include <stdio.h>
 #include <string.h>

 int main(void) {
    HFILE  hfFileHandle   = 0L;     /* Handle for file being manipulated */
    ULONG  ulAction       = 0;      /* Action taken by DosOpen */
    ULONG  ulBytesRead    = 0;      /* Number of bytes read by DosRead */
    ULONG  ulWrote        = 0;      /* Number of bytes written by DosWrite */
    ULONG  ulLocal        = 0;      /* File pointer position after
DosSetFilePtr
*/
    UCHAR  uchFileName[20]  = "dostest.dat",     /* Name of file */
           uchFileData[100] = " ";               /* Data to write to file */
    APIRET rc             = NO_ERROR;            /* Return code */

    /* Open the file test.dat.  Use an existing file or create a new */
    /* one if it doesn't exist.                                      */
    rc = DosOpen(uchFileName,                    /* File path name */
                 &hfFileHandle,                  /* File handle */
                 &ulAction,                      /* Action taken */
                 100L,                           /* File primary allocation */
                 FILE_ARCHIVED | FILE_NORMAL,    /* File attribute */
                 OPEN_ACTION_CREATE_IF_NEW |
                 OPEN_ACTION_OPEN_IF_EXISTS,     /* Open function type */
                 OPEN_FLAGS_NOINHERIT |
                 OPEN_SHARE_DENYNONE  |
                 OPEN_ACCESS_READWRITE,          /* Open mode of the file */
                 0L);                            /* No extended attribute */

    if (rc != NO_ERROR) {
       printf("DosOpen error: return code = %u\n", rc);
       return 1;
    } else {
      printf ("DosOpen: Action taken = %ld\n", ulAction);
    } /* endif */
    /* Write a string to the file */
    strcpy (uchFileData, "testing...\n1...\n2...\n3\n");

    rc = DosWrite (hfFileHandle,                /* File handle */
                   (PVOID) uchFileData,         /* String to be written */
                   sizeof (uchFileData),        /* Size of string to be
written
*/
                   &ulWrote);                   /* Bytes actually written */

    if (rc != NO_ERROR) {
       printf("DosWrite error: return code = %u\n", rc);
       return 1;
    } else {
       printf ("DosWrite: Bytes written = %u\n", ulWrote);
    } /* endif */

    /* Move the file pointer back to the beginning of the file */
    rc = DosSetFilePtr (hfFileHandle,           /* File Handle */
                        0L,                     /* Offset */
                        FILE_BEGIN,             /* Move from BOF */
                        &ulLocal);              /* New location address */
    if (rc != NO_ERROR) {
       printf("DosSetFilePtr error: return code = %u\n", rc);
       return 1;
    }

    /* Read the first 100 bytes of the file */
    rc = DosRead (hfFileHandle,                /* File Handle */
                  uchFileData,                 /* String to be read */
                  100L,                        /* Length of string to be read
*/
                  &ulBytesRead);               /* Bytes actually read */

    if (rc != NO_ERROR) {
       printf("DosRead error: return code = %u\n", rc);
       return 1;
    } else {
       printf ("DosRead: Bytes read = %u\n%s\n", ulBytesRead, uchFileData);
    } /* endif */

    rc = DosClose(hfFileHandle);                /* Close the file */

    if (rc != NO_ERROR) {
       printf("DosClose error: return code = %u\n", rc);
       return 1;
    }
    return NO_ERROR;
 }

 The following example shows how to open a communications port:



 #define INCL_DOSFILEMGR          /* File Manager values      */
 #define INCL_DOSERRORS           /* DOS Error values         */
 #define INCL_DOSPROCESS          /* DOS Process values       */
 #define INCL_DOSMISC             /* DOS Miscellanous values  */
 #include <os2.h>
 #include <stdio.h>
 #include <string.h>

 int main(void) {

 PSZ      pszCommPort    = "COM1";     /* Port name, could use "\\DEV\COM1" 
*/
 HFILE    hPort          = NULLHANDLE; /* Handle for accessing port         
*/
 ULONG    ulAction       = 0L;         /* DosOpen action                    
*/
 ULONG    ulWrote        = 0;          /* Number of bytes written to port   
*/
 UCHAR    uchPortData[100] = " ";      /* Data to write to port             
*/
 APIRET   rc             = NO_ERROR;   /* Return code                       
*/
 DosError( FERR_DISABLEHARDERR);       /* Disable hard error pop-up messages
*/
 rc = DosOpen( pszCommPort,            /* Communications port to open       
*/
               &hPort,
               &ulAction,              /* Returns action taken by DosOpen   
*/
               0L,                     /* Not needed for byte stream devices
*/
               FILE_NORMAL,
               OPEN_ACTION_OPEN_IF_EXISTS,
               OPEN_ACCESS_READWRITE |
               OPEN_FLAGS_NOINHERIT  |
               OPEN_SHARE_DENYREADWRITE ,  /* Prevents us from opening port
*/
                                           /* if another application is using
it
*/
                                           /* and prevents other applications
*/
                                           /* from using port while we have it
*/
               0L);                        /* No extended attributes
*/
 DosError( FERR_ENABLEHARDERR);            /* Re-enable hard error pop-ups
*/


 if (rc != NO_ERROR) {
   printf("DosOpen error: return code = %u\n", rc);
   return 1;
 } else {
   printf ("DosOpen: Action taken = %ld\n", ulAction);
 } /* endif */





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

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

From: mek@compuserve.com                                31-Aug-99 12:46:25
  To: All                                               31-Aug-99 16:34:24
Subj: Re: IPF-Limits

From: Mat Kramer <mek@compuserve.com>

Martin Bunzel FH wrote:
> does anybody know the limitations from the VA IPF-Compiler....

As you probably know, the IPF Reference lists limits as follows:

-----
     
      The maximum size of a line in an IPF source file is 255
characters. 

      The maximum number of fonts in a source file is 16. 

      The maximum number of unique words in a compiled file is 64 000. 

      The maximum number of unique words in a panel is 64 000. 

      The maximum number of panels is 64 000. 

      The maximum number of external databases is 255. 
  
  These maximum limits are not absolute. Activity in the operating
system can cause them to vary. 

-----

You may be running into the limit for "number of unique words", or as
another suggested, a system limit.  I've seen IPFC choke on a large file
and simply say "IPF File Too Big".

-- 
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: abuse@orac.clara.co.uk                            31-Aug-99 18:04:16
  To: All                                               31-Aug-99 16:34:24
Subj: Re: atoi access exception

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

On Mon, 30 Aug 1999 03:39:00 -0400 (EDT), Mike Ruskai
<thannymeister@yahoo.com> wrote:

>On Sat, 28 Aug 1999 23:42:35 GMT, Paul Ratcliffe wrote:
>
>>Really? Well then, in that case perhaps you can tell us all how you change
>>this pointer to point to something else?
>
>You don't, because it is a constant pointer.  Are you going to now say that a
>constant pointer isn't a pointer?

Don't be ridiculous, of course I'm not. If it's a pointer, then you can take
the address of it. Try doing it with an array and you'll find you can't, as
it's a number, and you can't take the address of a number.

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

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

From: abuse@orac.clara.co.uk                            31-Aug-99 18:04:17
  To: All                                               31-Aug-99 16:34:24
Subj: Re: atoi access exception

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

On Mon, 30 Aug 1999 04:16:04 -0400 (EDT), Mike Ruskai
<thannymeister@yahoo.com>
wrote:

>Not necessarily.  If the array is part of a structure, and the structure is
>allocated dynamically, the array data will not be on the stack, it will be on

You're modifying the conditions again by specifying dynamically. Why can't you
just stick to the original point?

>This is purely semantics.  The replacement may not be done by the
>preprocessor

"May not"? As has already been stated, the preprocessor knows nothing about
the
C language, therefore it is a case of "can not".

>but the replacement is done before the compiler sets to work.

In your version of things, what happens between the preprocessor and the
compiler?
I think you probably mean "code generator" where you say compiler. Sizeof will
be evaluated in the parse compilation phase and before code generation.
To say it's done before the compiler starts work is again meaningless.
 
>Another example, much simpler, with actual assembly:

Simpler? More complicated, as you have now clouded the issue with structs.

>struct foobar
>{
>    char foo1[64];
>};
>
>    pfoobar=(struct foobar*)malloc(sizeof(struct foobar));
>    foo2=(char*)malloc(sizeof(char)*64);

You are allocating dynamically the same amount of memory in both cases into
pointer variables....

>    for (i=0; i<64; i++)
>        {
>        afoo=pfoobar->foo1[i];
>        afoo=foo2[i];
>        }

...so it is not surprising that dereferencing them generates the same code.

>As you can see, the assembly is the same for both the explicit array and
>dynamic array, because they are both located on the heap.  Only if you
>allocate the array on the stack will the behavior of the symbol be different.

Sorry, this is garbage. Try generating assembler for this:

char a[64];
char *b = a;

void main(void)
{
  volatile char c;

  c = a[1];
  c = b[1];
}

Neither a nor b is on the stack, they both address the same memory, yet the
code for getting the value into c is rather different.

; 8   c = a[1];
	mov	al,byte ptr  a+01h
	mov	[ebp-01h],al;	c

; 9   c = b[1];
	mov	eax,dword ptr  b
	mov	al,[eax+01h]
	mov	[ebp-01h],al;	c

b is a pointer, a is an array. They are not the same.
QED.

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

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

From: abuse@orac.clara.co.uk                            31-Aug-99 18:04:18
  To: All                                               31-Aug-99 16:34:24
Subj: Re: atoi access exception

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

On Mon, 30 Aug 1999 12:28:26 -0600, Hubert Chan <hubert@ugrad.cs.ualberta.ca>
wrote:

>Actually, it looks like this shows that foo2 and foo1 are different types.
>When you do pfoobar->foo1[i], you would be doing 2 dereferences if foo1
>were a pointer.  Once dereferencing pfoobar, and once dereferencing
>foo1+i.  But here, the compiler only does one.

An exellent point.

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

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

From: abuse@orac.clara.co.uk                            31-Aug-99 18:04:20
  To: All                                               31-Aug-99 16:34:24
Subj: Re: atoi access exception

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

On Sat, 28 Aug 1999 21:13:55 -0400, Marty <mamodeo@stny.rr.com> wrote:

>I take a very low-level view of things generally.  I tend to view
>high-level language constructs as "smoke and mirrors".  Just a matter of
>differing perspectives I guess.

Maybe, although having a low-level view of things generally means you
understand exactly how things work - in this case at assembler level. And C is
just a high level assembler, so it's said :-)
Perhaps it passed you by on this occasion.

>Understood.  No hard feelings.

Likewise.

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

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

From: abuse@orac.clara.co.uk                            31-Aug-99 18:04:21
  To: All                                               31-Aug-99 16:34:24
Subj: Re: atoi access exception

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

On Sat, 28 Aug 1999 21:20:04 -0400, Marty <mamodeo@stny.rr.com> wrote:

>Paul Ratcliffe wrote:
>> 
>> I await an apology from Mr Ruskai. Somehow I doubt it will be forthcoming.
>
>I certainly wish to apologize for being unclear and wrong.

And I wish to apologize for being mildly obnoxious to anyone who was so
offended. This is not an admission of being wrong though, 'cos I'm not :-)

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

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

From: glen@rockyhorror.Zkaroo.co.uk                     31-Aug-99 19:15:00
  To: All                                               31-Aug-99 16:34:25
Subj: Opening a drive with DosOpen()

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

Hi all,

I'm trying to use DosOpen to get a HFILE pointing to the C: drive.  
Here's how I'm doing it.

----
char drv[]="C:";

rc=DosOpen(drv, &hc, &act, 0, FILE_NORMAL, OPEN_ACTION_OPEN_IF_EXISTS,
OPEN_FLAGS_DASD, NULL);
----

I get an ERROR_INVALID_ACCESS returned.  What am I doing wrong?

TIA.

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: nospamaddress@nowhere.on.the.net                  31-Aug-99 19:47:04
  To: All                                               31-Aug-99 20:08:13
Subj: Re: Opening a drive with DosOpen()

From: nospamaddress@nowhere.on.the.net (Jeroen)

Glen,

The sharing mode has not been specified! Bits 6 thru 4 of parameter 7 
MUST be non-zero. Currently you only have OPEN_FLAGS_DASD specified 
here. Do a logical OR with any OPEN_SHARE_xxxx and you'll be okay.

Jeroen

On Tue, 31 Aug 1999 19:15:00, glen@rockyhorror.Zkaroo.co.uk (Glen D) 
wrote:

> Hi all,
> 
> I'm trying to use DosOpen to get a HFILE pointing to the C: drive.  
> Here's how I'm doing it.
> 
> ----
> char drv[]="C:";
> 
> rc=DosOpen(drv, &hc, &act, 0, FILE_NORMAL, OPEN_ACTION_OPEN_IF_EXISTS,
> OPEN_FLAGS_DASD, NULL);
> ----
> 
> I get an ERROR_INVALID_ACCESS returned.  What am I doing wrong?
> 
> TIA.
> 
> Glen D
> -<remove Z from my e-mail address>-


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

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

From: mamodeo@stny.rr.com                               31-Aug-99 17:59:08
  To: All                                               31-Aug-99 21:19:21
Subj: Re: Is anything wrong with this PM code??

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

Jasper de Keijzer wrote:
> 
> Marty,
> 
> One of the things I encounter in your code is the fact that you do not
> initialize the BITMAPINFOHEADER and the BITMAPINFO2 structs to zero
> memset((void *)&bmpinf,0,sizeof(BITMAPINFOHEADER)). I've had exactly the
> same problem and this fixed it for me.

Nope.  That didn't do it.  :-(

In every such case where I open the memory device context it doesn't
display anything at all.  Is there something wrong with that part of the
code?

- Marty

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

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

From: mamodeo@stny.rr.com                               31-Aug-99 18:43:27
  To: All                                               01-Sep-99 10:43:22
Subj: Re: Is anything wrong with this PM code??

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

Jasper de Keijzer wrote:
> 
> Marty,
> 
> One of the things I encounter in your code is the fact that you do not
> initialize the BITMAPINFOHEADER and the BITMAPINFO2 structs to zero
> memset((void *)&bmpinf,0,sizeof(BITMAPINFOHEADER)). I've had exactly the
> same problem and this fixed it for me.

One more update:
Everything is ok until I go to get the bitmap handle created with
GpiCreateBitmap (bmp).  bmp winds up being 0 and everything is down-hill
from there.  Any more ideas?

- Marty

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

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

From: ekadakal@aol.com                                  31-Aug-99 23:28:12
  To: All                                               01-Sep-99 10:43:23
Subj: -<ERROR>- unable to open transport

From: ekadakal@aol.com (EKadakal)

Hi Everyone:

I get the follwing error (in tracing) when I try to access an Oracle database
from a Warp 4 client machine. Any idea?

-<ERROR>- soc -1 error - operation=3, ntresnt[0]=530,
ntresnt[1]=-3,ntresnt[2]=0
-<ERROR>- nsres: id=0, op=65, ns=12560, ns2=0; nt[0]=530, nt[1]=-3, nt[2]=0
-<ERROR>- unable to open transport

Thanks

Ercan

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

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

From: abuse@orac.clara.co.uk                            31-Aug-99 23:39:13
  To: All                                               01-Sep-99 10:43:23
Subj: Re: Web Explorer Toolkit

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

On Tue, 31 Aug 1999 12:36:26 GMT, putmanh@my-deja.com <putmanh@my-deja.com>
wrote:

>application running under OS/2. I remember a while back there was a
>WebExplorer toolkit that let you do this. It seems to have disappeared.
>Does anyone have a copy of this or know where I can get it. I know the

Yes, I have the docs. and the toolkit. Mail me if you can't find it elsewhere.

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

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

From: mamodeo@stny.rr.com                               31-Aug-99 22:37:09
  To: All                                               01-Sep-99 10:43:24
Subj: Re: Is anything wrong with this PM code??

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

I solved it I think.  For anyone interested, here's the problem:
>                         BITMAPINFO2 bmpi;
...
>                         bmpi.cbFix = sizeof(BITMAPINFO2);

I was getting an "Invalid length or count" return code from
GpiCreateBitmap.  Those two lines should have been:
>                         BITMAPINFOHEADER2 bmpi;
...
>                         bmpi.cbFix = sizeof(BITMAPINFOHEADER2);

These two structures apparently have different lengths, and the former is
not accepted or recognized by GRADD drivers.

- Marty

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

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

From: stantowianski@home.com                            01-Sep-99 02:45:03
  To: All                                               01-Sep-99 14:27:05
Subj: Re: Pipes( > < | ) do text only?

From: Stan Towianski <stantowianski@home.com>

Hi,

Thanks, but that does not look easier to read.
The other person's suggestion still does not seem to work.
See their note.

bv wrote:

> Stan Towianski wrote:
>
> > I am using IBM's C/C++ 2.01 (?) compiler.  I am writing in C.
> > These are all my fopen stmt.s:
> >             else if ( ( out = fopen( newname, "rb") ) != NULL )
> >
>
> ... etc
>
> > It looks to me like OS/2's >  <  and |  are automatically changing LF
> > to CRLF and vice-versa which it sounds like means they are opening files
> > in text mode.
>
> The command line redirection in OS/2 is not designed for any heavy use, as
far as
> I recall.
> In any case, the OS/2 command shell is not supposed to be compatible with
any
> UNIX shell.
>
> This is a very inefficient method for interprogram communication in a
> multithreaded operating system, and there are much better mechanisms
available in
> the OS/2 API. You can use named or unnamed pipes, message queues or other
IPC
> mechanisms.
>
> This goes for file handling, too. Generally, it is both safer and better to
use
> the OS/2 APIs for OS/2 programs instead of the general purpose POSIX/c
library
> ones.
>
> This leads to a different recommended programming style from what is common
in
> the UNIX world. An added advantage is that the code is easier to read for
other
> people. For instance, from the reference in the Developer Toolkit:
>
>  This example opens or creates and opens a normal file named "DOSTEST.DAT",
>  writes to it, reads from it, and finally closes it.
>
>  #define INCL_DOSFILEMGR          /* File Manager values */
>  #define INCL_DOSERRORS           /* DOS Error values    */
>  #include <os2.h>
>  #include <stdio.h>
>  #include <string.h>
>
>  int main(void) {
>     HFILE  hfFileHandle   = 0L;     /* Handle for file being manipulated */
>     ULONG  ulAction       = 0;      /* Action taken by DosOpen */
>     ULONG  ulBytesRead    = 0;      /* Number of bytes read by DosRead */
>     ULONG  ulWrote        = 0;      /* Number of bytes written by DosWrite
*/
>     ULONG  ulLocal        = 0;      /* File pointer position after
DosSetFilePtr
> */
>     UCHAR  uchFileName[20]  = "dostest.dat",     /* Name of file */
>            uchFileData[100] = " ";               /* Data to write to file */
>     APIRET rc             = NO_ERROR;            /* Return code */
>
>     /* Open the file test.dat.  Use an existing file or create a new */
>     /* one if it doesn't exist.                                      */
>     rc = DosOpen(uchFileName,                    /* File path name */
>                  &hfFileHandle,                  /* File handle */
>                  &ulAction,                      /* Action taken */
>                  100L,                           /* File primary allocation
*/
>                  FILE_ARCHIVED | FILE_NORMAL,    /* File attribute */
>                  OPEN_ACTION_CREATE_IF_NEW |
>                  OPEN_ACTION_OPEN_IF_EXISTS,     /* Open function type */
>                  OPEN_FLAGS_NOINHERIT |
>                  OPEN_SHARE_DENYNONE  |
>                  OPEN_ACCESS_READWRITE,          /* Open mode of the file */
>                  0L);                            /* No extended attribute */
>
>     if (rc != NO_ERROR) {
>        printf("DosOpen error: return code = %u\n", rc);
>        return 1;
>     } else {
>       printf ("DosOpen: Action taken = %ld\n", ulAction);
>     } /* endif */
>     /* Write a string to the file */
>     strcpy (uchFileData, "testing...\n1...\n2...\n3\n");
>
>     rc = DosWrite (hfFileHandle,                /* File handle */
>                    (PVOID) uchFileData,         /* String to be written */
>                    sizeof (uchFileData),        /* Size of string to be
written
> */
>                    &ulWrote);                   /* Bytes actually written */
>
>     if (rc != NO_ERROR) {
>        printf("DosWrite error: return code = %u\n", rc);
>        return 1;
>     } else {
>        printf ("DosWrite: Bytes written = %u\n", ulWrote);
>     } /* endif */
>
>     /* Move the file pointer back to the beginning of the file */
>     rc = DosSetFilePtr (hfFileHandle,           /* File Handle */
>                         0L,                     /* Offset */
>                         FILE_BEGIN,             /* Move from BOF */
>                         &ulLocal);              /* New location address */
>     if (rc != NO_ERROR) {
>        printf("DosSetFilePtr error: return code = %u\n", rc);
>        return 1;
>     }
>
>     /* Read the first 100 bytes of the file */
>     rc = DosRead (hfFileHandle,                /* File Handle */
>                   uchFileData,                 /* String to be read */
>                   100L,                        /* Length of string to be
read */
>                   &ulBytesRead);               /* Bytes actually read */
>
>     if (rc != NO_ERROR) {
>        printf("DosRead error: return code = %u\n", rc);
>        return 1;
>     } else {
>        printf ("DosRead: Bytes read = %u\n%s\n", ulBytesRead, uchFileData);
>     } /* endif */
>
>     rc = DosClose(hfFileHandle);                /* Close the file */
>
>     if (rc != NO_ERROR) {
>        printf("DosClose error: return code = %u\n", rc);
>        return 1;
>     }
>     return NO_ERROR;
>  }
>
>  The following example shows how to open a communications port:
>
>  #define INCL_DOSFILEMGR          /* File Manager values      */
>  #define INCL_DOSERRORS           /* DOS Error values         */
>  #define INCL_DOSPROCESS          /* DOS Process values       */
>  #define INCL_DOSMISC             /* DOS Miscellanous values  */
>  #include <os2.h>
>  #include <stdio.h>
>  #include <string.h>
>
>  int main(void) {
>
>  PSZ      pszCommPort    = "COM1";     /* Port name, could use "\\DEV\COM1"  
*/
>  HFILE    hPort          = NULLHANDLE; /* Handle for accessing port          
*/
>  ULONG    ulAction       = 0L;         /* DosOpen action                     
*/
>  ULONG    ulWrote        = 0;          /* Number of bytes written to port    
*/
>  UCHAR    uchPortData[100] = " ";      /* Data to write to port              
*/
>  APIRET   rc             = NO_ERROR;   /* Return code                        
*/
>  DosError( FERR_DISABLEHARDERR);       /* Disable hard error pop-up messages 
*/
>  rc = DosOpen( pszCommPort,            /* Communications port to open        
*/
>                &hPort,
>                &ulAction,              /* Returns action taken by DosOpen    
*/
>                0L,                     /* Not needed for byte stream devices 
*/
>                FILE_NORMAL,
>                OPEN_ACTION_OPEN_IF_EXISTS,
>                OPEN_ACCESS_READWRITE |
>                OPEN_FLAGS_NOINHERIT  |
>                OPEN_SHARE_DENYREADWRITE ,  /* Prevents us from opening port
> */
>                                            /* if another application is
using it
> */
>                                            /* and prevents other
applications
> */
>                                            /* from using port while we have
it
> */
>                0L);                        /* No extended attributes
> */
>  DosError( FERR_ENABLEHARDERR);            /* Re-enable hard error pop-ups
> */
>
>  if (rc != NO_ERROR) {
>    printf("DosOpen error: return code = %u\n", rc);
>    return 1;
>  } else {
>    printf ("DosOpen: Action taken = %ld\n", ulAction);
>  } /* endif */

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

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

From: stantowianski@home.com                            01-Sep-99 02:55:03
  To: All                                               01-Sep-99 14:27:05
Subj: Re: Pipes( > < | )  do text only?

From: Stan Towianski <stantowianski@home.com>

Hi,

Thanks.  I did not think of that.  I tried it and that does not seem
to work though either.  Close to the top, after main() I added what you said:
first: #include <fcntl.h>      <=  needed this too.

main()
...

/* get the filehandle to stdout */
/* force stdout to display using binary instead of text */
rc = _fileno( stdout );
/*fprintf( stderr, "rc handle # for stdout =%d", rc );*/
_setmode( rc, O_BINARY );
fprintf( stderr, "rc for setmode for stdout =%d\n", rc );
gets( ans );                    <== I get:  rc for setmode for stdout =1

/* get the filehandle to stdin */
/* force stdin to display using binary instead of text */
rc = _fileno( stdin );
_setmode( rc, O_BINARY );

...
        rc = fread( f_line, 1, seg_size, in );
        fprintf( stderr, "\rread bytes = %d", rc );

...
        rc = fwrite( f_line, rc, 1, out );
        fprintf( stderr, "\rwrote bytes = %d", rc );
        } /* end while */


in sub to open output file:
        if ( *newname == '-' )
            {
            out = stdout;
            fprintf( stderr, "Writing stdout\n" );
            }


when I do cat.exe config.sys >out
I get a bigger out file with the newlines added:
 8-28-99   8:55a      7605           0  CONFIG.SYS   (contains 191 lines)
 8-31-99  10:50p      7796           0  out

charette@writeme.com wrote:

> In <37CBC258.D9797845@home.com>, Stan Towianski <stantowianski@home.com>
writes:
> >I am using IBM's C/C++ 2.01 (?) compiler.  I am writing in C.
> >These are all my fopen stmt.s:
>
> [cut]
>
> You are setting stdout to binary mode as well, right?
>
> Here is a code snippet from some old app I wrote many years ago:
>
>    /* get the filehandle to stdout */
>    int filehandle = _fileno( stdout );
>    /* force stdout to display using binary instead of text */
>    _setmode( filehandle, O_BINARY );
>
> Stephane Charette
> charette@writeme.com

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

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

From: thannymeister@spambegone.yahoo.com                01-Sep-99 03:00:00
  To: All                                               01-Sep-99 17:47:19
Subj: Re: atoi access exception

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

On Tue, 31 Aug 1999 18:04:34 GMT, Paul Ratcliffe wrote:

>On Mon, 30 Aug 1999 04:16:04 -0400 (EDT), Mike Ruskai
<thannymeister@yahoo.com>
>wrote:
>
>>Not necessarily.  If the array is part of a structure, and the structure is
>>allocated dynamically, the array data will not be on the stack, it will be
on
>
>You're modifying the conditions again by specifying dynamically. Why can't
you
>just stick to the original point?

If you think that where the data is stored is part of the conditions
necessary to maintain your claims, then you're on a faulty foundation.

>>This is purely semantics.  The replacement may not be done by the
>>preprocessor
>
>"May not"? As has already been stated, the preprocessor knows nothing about
the
>C language, therefore it is a case of "can not".

There's no requirement than a compiler use a preprocessor that's ignorant of
C syntax.

>>but the replacement is done before the compiler sets to work.
>
>In your version of things, what happens between the preprocessor and the
>compiler?
>I think you probably mean "code generator" where you say compiler. Sizeof
will
>be evaluated in the parse compilation phase and before code generation.
>To say it's done before the compiler starts work is again meaningless.

Semantics again.  But have it your way.

>>Another example, much simpler, with actual assembly:
>
>Simpler? More complicated, as you have now clouded the issue with structs.

If you can't see why it's simpler, then you didn't see the first example.

And surely someone as wise and learned in the ways of True C could not have
judgmented clouded by the use simple structures.

>>struct foobar
>>{
>>    char foo1[64];
>>};
>>
>>    pfoobar=(struct foobar*)malloc(sizeof(struct foobar));
>>    foo2=(char*)malloc(sizeof(char)*64);
>
>You are allocating dynamically the same amount of memory in both cases into
>pointer variables....

Irrelevant, of course.

>>    for (i=0; i<64; i++)
>>        {
>>        afoo=pfoobar->foo1[i];
>>        afoo=foo2[i];
>>        }
>
>....so it is not surprising that dereferencing them generates the same code.

Perhaps you weren't reading clearly.  The above is not using the subscript
operator on the structure, but the structure's element, which is an array
object, an example of the entire point of contentions of this discussion.

The reason that the assembly is the same is because both the explicit pointer
and the implicit pointer of the array object (to use the semantics that
should make you comfortable) are treated precisely the same.

By using a dynamically allocated structure, I've removed the obfuscation of
what type of storage is being used to contain the array data.

>>As you can see, the assembly is the same for both the explicit array and
>>dynamic array, because they are both located on the heap.  Only if you
>>allocate the array on the stack will the behavior of the symbol be
different.
>
>Sorry, this is garbage. Try generating assembler for this:
>
>char a[64];
>char *b = a;
>
>void main(void)

Void?  A language lawyer using void?!  For shame!

>{
>  volatile char c;
>
>  c = a[1];
>  c = b[1];
>}
>
>Neither a nor b is on the stack, they both address the same memory, yet the
>code for getting the value into c is rather different.
>
>; 8   c = a[1];
>	mov	al,byte ptr  a+01h
>	mov	[ebp-01h],al;	c
>
>; 9   c = b[1];
>	mov	eax,dword ptr  b
>	mov	al,[eax+01h]
>	mov	[ebp-01h],al;	c
>
>b is a pointer, a is an array. They are not the same.
>QED.

If the above difference were due to a difference between types, then why did
my example show no difference?


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: thannymeister@spambegone.yahoo.com                01-Sep-99 03:01:03
  To: All                                               01-Sep-99 17:47:19
Subj: Re: atoi access exception

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

On Tue, 31 Aug 1999 18:04:32 GMT, Paul Ratcliffe wrote:

>On Mon, 30 Aug 1999 03:39:00 -0400 (EDT), Mike Ruskai
><thannymeister@yahoo.com> wrote:
>
>>On Sat, 28 Aug 1999 23:42:35 GMT, Paul Ratcliffe wrote:
>>
>>>Really? Well then, in that case perhaps you can tell us all how you change
>>>this pointer to point to something else?
>>
>>You don't, because it is a constant pointer.  Are you going to now say that
a
>>constant pointer isn't a pointer?
>
>Don't be ridiculous, of course I'm not. If it's a pointer, then you can take
>the address of it. Try doing it with an array and you'll find you can't, as
>it's a number, and you can't take the address of a number.

You're confusing a pointer with a pointer variable.


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: ivaes@hr.nl                                       01-Sep-99 12:55:24
  To: All                                               01-Sep-99 17:47:19
Subj: Re: Is anything wrong with this PM code??

From: Illya Vaes <ivaes@hr.nl>

Marty wrote:
>       case WM_CREATE: {
[...]
>           hdc = DevOpenDC( WinQueryAnchorBlock( win ), OD_MEMORY, "*", 5,

What's "win"? I didn't see it in your declarations.
Note that you may not use the HWND parameter of the message in a WM_CREATE
message, since it is not guaranteed to have been filled yet (or is it
guaranteed not to have been filled?), according to the documentation.
How'bout using the HAB value that you get from WinInitialize() instead of
querying it with WinQueryAnchorBlock()?

-- 
Illya Vaes   (ivaes@hr.nl)        "Do...or do not, there is no 'try'" - Yoda
Holland Railconsult BV, Integral Management of Railprocess Systems
Postbus 2855, 3500 GW Utrecht
Tel +31.30.2357382, Fax 2357395           Not speaking for anyone but myself

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

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

From: DCritel@ibm.net                                   01-Sep-99 09:30:08
  To: All                                               01-Sep-99 17:47:19
Subj: Rexx - working w/sys err msgs.

From: Dave Critelli <DCritel@ibm.net>

Anyone know how to respond (intercept) to a Warp system error message in
a Rexx IF statement?

For example a "SYS0015: The system cannot find the specified drive."

Thanks
Dave

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

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

From: mamodeo@stny.rr.com                               01-Sep-99 09:38:04
  To: All                                               01-Sep-99 17:47:19
Subj: Re: Is anything wrong with this PM code??

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

Illya Vaes wrote:
> 
> Marty wrote:
> >       case WM_CREATE: {
> [...]
> >           hdc = DevOpenDC( WinQueryAnchorBlock( win ), OD_MEMORY, "*", 5,
> 
> What's "win"?  I didn't see it in your declarations.

HWND

> Note that you may not use the HWND parameter of the message in a WM_CREATE
> message, since it is not guaranteed to have been filled yet (or is it
> guaranteed not to have been filled?), according to the documentation.

Works fine.  The HWND is associated with an anchor block right away, so
this is fine to do.

> How'bout using the HAB value that you get from WinInitialize() instead of
> querying it with WinQueryAnchorBlock()?

Because it is possible for other threads to use the same window
procedure my way.

- Marty

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

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

From: Flass@Leginfo.LBDC.State.NY.US                    01-Sep-99 10:02:14
  To: All                                               01-Sep-99 17:47:19
Subj: ALP Syntax question

From: Peter Flass <Flass@Leginfo.LBDC.State.NY.US>

I'm trying to find the correct syntax.
I want to call a function indirectly thru a vector table.  Assume EDI
points to a table of function addresses.  I tried the obvious -
          CALL 8[EDI] 
     for example, and ALP generates a warning message -
   "Warning ALP4501: Assuming NEAR distance for       operand size".

Apparently the correct code is being generated, but the warning is
annoying.  I tried playing with casting, but can't seem to find syntax
that works.
Naturally I'm using ".model flat".

Any assembler gurus out there that can help?  TIA.

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

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

From: mamodeo@stny.rr.com                               01-Sep-99 10:29:07
  To: All                                               01-Sep-99 17:47:20
Subj: Re: ALP Syntax question

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

Peter Flass wrote:
> 
> I'm trying to find the correct syntax.
> I want to call a function indirectly thru a vector table.  Assume EDI
> points to a table of function addresses.  I tried the obvious -
>           CALL 8[EDI]
>      for example, and ALP generates a warning message -
>    "Warning ALP4501: Assuming NEAR distance for       operand size".
> 
> Apparently the correct code is being generated, but the warning is
> annoying.  I tried playing with casting, but can't seem to find syntax
> that works.
> Naturally I'm using ".model flat".
> 
> Any assembler gurus out there that can help?  TIA.

Not a guru by any means, but maybe it's referring to the constant (8). 
Is there some way to turn that into a "32-bit" 8 or at least specifying
that 16-bit is a-ok?

Also, double-check that you're producing 32 bit stuff using EXEHDR on
the resulting executable.

- Marty

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

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

From: csaba.raduly@sophos.com                           01-Sep-99 14:59:24
  To: All                                               01-Sep-99 17:47:20
Subj: Re: Web Explorer Toolkit

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

fonz@gmx.at wrote:
> 
> On Tue, 31 Aug 1999 12:36:26, putmanh@my-deja.com wrote:
> 
> > I am looking for a way to show web pages in an arbitrary window in my
> > application running under OS/2. I remember a while back there was a
> > WebExplorer toolkit that let you do this. It seems to have disappeared.
> > Does anyone have a copy of this or know where I can get it. I know the
> > HTML support is not up tyo today's standards, but I'm willing to live
> > with that.
> 
> 
> it was hard to find webex, but here it is:
> http://www.networking.ibm.com/WebExplorer/webhome.htm
> (you only need webexwin.dll and webexurl.dll)
> 
> i can't remember if the api-doku is included
> (i have found it somewhere at hobbes, look for webex)
> 
> fonz

No, the toolkit's not there :-(
Even the link to download WebExplorer 1.1h is broken.
I definitely couldn't find ANY reference to the toolkit.
Do a ftpsearch for webex and you'll have better chances.

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 Bridge ClubN (1:109/42)

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

From: thannymeister@spambegone.yahoo.com                01-Sep-99 12:51:01
  To: All                                               01-Sep-99 17:47:20
Subj: Re: Rexx - working w/sys err msgs.

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

On Wed, 01 Sep 1999 09:30:17 -0400, Dave Critelli wrote:

>Anyone know how to respond (intercept) to a Warp system error message in
>a Rexx IF statement?
>
>For example a "SYS0015: The system cannot find the specified drive."

There is no way in REXX, but I just wrote (literally) an extension DLL to do
it.

You can get it at:

 ftp://hobbes.nmsu.edu/pub/incoming/RxError.zip

When archived, it'll be at:

ftp://hobbes.nmsu.edu/pub/os2/dev/rexx/RxError.zip

When you download it, copy RxError.dll to a directory in the libpath, and put
this in your REXX program:

call RxFuncAdd 'RxError','RxError','RxError'

Then when you are going to do something which may cause a hard error pop-up
(such as changing to an invalid drive), do this:

call RxError 'dh'

After you're done, you should do this, to re-enable hard errors:

call RxError 'eh'


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: fBeythien@gmx.de                                  01-Sep-99 18:04:09
  To: All                                               01-Sep-99 19:58:09
Subj: Re: Rexx - working w/sys err msgs.

From: fBeythien@gmx.de (Frank Beythien)

On Wed, 1 Sep 1999 13:30:17, Dave Critelli <DCritel@ibm.net> wrote:

> Anyone know how to respond (intercept) to a Warp system error message in
> a Rexx IF statement?
> 
> For example a "SYS0015: The system cannot find the specified drive."

Why not do it the other way around: SysDriveMap from REXXUTIL gives 
all valid Drive letters. 

Or, as you did not show the command which leads to the error msg, an 
example with the dir command
 
'@dir u: 1>nul 2>nul'


CU/2
-- 
Frank Beythien   fBeythien@gmx.de

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Prima e.V. - Dortmund - Germany (1:109/42)

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

From: ekadakal@aol.com                                  01-Sep-99 21:23:05
  To: All                                               01-Sep-99 21:47:11
Subj: What is IBMNULL print driver is for

From: ekadakal@aol.com (EKadakal)

Hello Everyone:

The problem is:

I have removed all printers from Warp4 printer folder. However when I do Print
Screen from FULL SCREEN applications (DOS or OS/2), it still prints through
the
LPT1 if there is a printer attached. However if no printer is attached, then
it
completely locks up when presses PrintScreen on a DELL Gn Optiplex machine. 

I am suspicious that the printing is done via IBMNULL, but why is that it
would
lock up if there is no printer attached

Does anyone have any idea?

Regards

John

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

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

From: abuse@orac.clara.co.uk                            01-Sep-99 23:47:24
  To: All                                               02-Sep-99 06:35:00
Subj: Re: atoi access exception

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

On Wed, 01 Sep 1999 03:00:01 -0400 (EDT), Mike Ruskai
<thannymeister@yahoo.com>
wrote:

>And surely someone as wise and learned in the ways of True C could not have
>judgmented clouded by the use simple structures.

My parser declares this an illegal sentence and gives a fatal error.

>>>        afoo=pfoobar->foo1[i];
>>>        afoo=foo2[i];
>
>Perhaps you weren't reading clearly.  The above is not using the subscript
>operator on the structure, but the structure's element, which is an array

Yes, I do know the difference.

>object, an example of the entire point of contentions of this discussion.

You have conveniently ignored the comment someone else made that there are
two dereferences in the first line and only one in the second, yet they
generate the same code. How then can this be if they are of the same type?

>By using a dynamically allocated structure, I've removed the obfuscation of
>what type of storage is being used to contain the array data.

So why doesn't this work when they are both statically allocated as in my
example?

>>void main(void)
>
>Void?  A language lawyer using void?!  For shame!

What are you talking about? What's wrong with void? This function takes no
arguments and returns no value? How the fuck are you supposed to declare it?

>If the above difference were due to a difference between types, then why did
>my example show no difference?

If the above difference were not due to a difference between types, then why
did my example show a difference?

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

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

From: abuse@orac.clara.co.uk                            01-Sep-99 23:47:25
  To: All                                               02-Sep-99 06:35:00
Subj: Re: Is anything wrong with this PM code??

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

On Wed, 01 Sep 1999 12:55:48 +0200, Illya Vaes <ivaes@hr.nl> wrote:

>Marty wrote:
>>       case WM_CREATE: {
>[...]
>>           hdc = DevOpenDC( WinQueryAnchorBlock( win ), OD_MEMORY, "*", 5,
>
>What's "win"? I didn't see it in your declarations.
>Note that you may not use the HWND parameter of the message in a WM_CREATE
>message, since it is not guaranteed to have been filled yet (or is it
>guaranteed not to have been filled?), according to the documentation.

If it does say that, and I can't believe it does (but I haven't checked), then
it is certainly wrong. The window must be created before you can send messages
to it, and it is totally ridiculous not to have your own window handle when
you receive WM_CREATE.
Logic and experience tell me this is not true.

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

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

From: jon@smartpeopleinc.com                            02-Sep-99 01:28:16
  To: All                                               02-Sep-99 06:35:00
Subj: a valuable resource for Web/e-Commerce integration answers and jobs

From: "Smart People" <jon@smartpeopleinc.com>

iSmart People.com in just a few days will offer our iSmart Centre where
developers and integrators can share technical problems and solutions
and network with your peers across the continent. Through our technical
forums,
we will host on going discussion topics such as OO Design and Development,
Java,
Web Development, Windows solutions, Linux Web Integration, Internet/Intranet
Integration and e-Commerce integration topics in moderated forums, where you
don't have to worry about a unsolicited postings interrupting professional
discussions.

In addition, confidentially register your technical profile and our iSmart
Notification
feature brings the career or contract to you, within your skills niche, at
the dollars you
require, from the location you desire. Whether your an active career or
contract seeker or just keeping your options open, post your profile with us
at http://www.ismartpeople.com and keep in tune with what High-Tech offers
you across North America. Our iSmart Jobs will be activated September 16th.

We're here for you as a specialized professional and look forward to helping
you. We hope you'll forward this message to your colleages and contacts. If
you have questions please do not hesitate to drop us an e-mail at
info@ismartpeople.com


Thanks for your interest

iSmart People.com









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

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

From: stantowianski@home.com                            02-Sep-99 02:00:04
  To: All                                               02-Sep-99 06:35:00
Subj: Re: Pipes( > < | )  do text only?

From: Stan Towianski <stantowianski@home.com>

From a user that just emailed I received the answer.
This seems to have worked for me.  The _setmode did not, but
freopen() does.
----------------------
I owe you an apology.  First, an explanation - I set stdin and stdout to
binary mode all the time - using the emx compiler. In that environment
it's _fsetmode() that does it.

I haven't used C/Set in ages - but I've done this before, and only by
reading the docs, too.

The following sets stdin and stdout to binary mode for C/set.  Go read the
C lib docs to find out why.

freopen("","rb",stdin);
freopen("","wb",stdout);

Stan Towianski wrote:

> I am using IBM's C/C++ 2.01 (?) compiler.  I am writing in C.
> These are all my fopen stmt.s:
>             else if ( ( out = fopen( newname, "rb") ) != NULL )
>         else if ( ( out = fopen( newname, "rb") ) != NULL )
>         if ( ( out = fopen( newname, "ab") ) == NULL )
>         if ( ( out = fopen( newname, "wb") ) == NULL )
>             else if ( ( in = fopen( newname, "rb") ) == NULL )
>         else if ( ( in = fopen( newname, "rb") ) == NULL )
>
> It looks to me like OS/2's >  <  and |  are automatically changing LF
> to CRLF and vice-versa which it sounds like means they are opening files
> in text mode.
>
> Paul Ratcliffe wrote:
>
> > On Sat, 28 Aug 1999 18:14:44 GMT, Stan Towianski <stantowianski@home.com>
> > wrote:
> >
> > >I wrote a cat.exe which write out a file's contents in binary.
> > >I think the program is working, but when I redirect is with
> > >| or > I think these are only allowing text mode file operations!
> >
> > You are opening the file in text mode by the sound of it, when you really
> > want binary mode. How you select this is dependant on language/compiler
and
> > you don't say which you are using.....

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

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

From: dwhawk@southwind.net                              02-Sep-99 03:41:14
  To: All                                               02-Sep-99 06:35:00
Subj: Re: What is IBMNULL print driver is for

From: dwhawk@southwind.net (Don Hawkinson)

In <19990901172311.02096.00000658@ng-ca1.aol.com>, ekadakal@aol.com (EKadakal) 
writes:
>Hello Everyone:
>

>I am suspicious that the printing is done via IBMNULL, but why is that it
would
>lock up if there is no printer attached

>Does anyone have any idea?

The IBMNULL.DRV printer driver, which is installed by default when you 
install a printer.  This driver supports printers that receive straight
ASCII data.                            

In Warp 3, you can disable the print screen option.  I suspect that 
Warp 4 has the same feature, but I don't want to reboot to check.

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

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

From: cwr@cts.com                                       02-Sep-99 12:24:22
  To: All                                               02-Sep-99 15:03:08
Subj: Re: Pipes( > < | )  do text only?

From: Will Rose <cwr@cts.com>

In comp.os.os2.programmer.misc Stan Towianski <stantowianski@home.com> wrote:
: I am using IBM's C/C++ 2.01 (?) compiler.  I am writing in C.
: These are all my fopen stmt.s:
:             else if ( ( out = fopen( newname, "rb") ) != NULL )
:         else if ( ( out = fopen( newname, "rb") ) != NULL )
:         if ( ( out = fopen( newname, "ab") ) == NULL )
:         if ( ( out = fopen( newname, "wb") ) == NULL )
:             else if ( ( in = fopen( newname, "rb") ) == NULL )
:         else if ( ( in = fopen( newname, "rb") ) == NULL )

: It looks to me like OS/2's >  <  and |  are automatically changing LF
: to CRLF and vice-versa which it sounds like means they are opening files
: in text mode.

Looking back at some old filter code I wrote, I _think_ stdin and stdout
default to binary under VAC++.  Anyway, here's some sample code I used to
convert stdout to text mode:
	fp_out = stdout;
	if (setmode(fileno(fp_out), O_TEXT) == FAILED)
		fprintf(stderr, "Cannot change output fp mode.\n");

There are also several patches in the code for MSDOS, so it looks as
if the open mode varies with the OS/compiler.


Will
cwr@crash.cts.com


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

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

From: jstucklex@ibm.net                                 02-Sep-99 09:04:24
  To: All                                               02-Sep-99 15:03:08
Subj: Re: atoi access exception

From: Jerry Stuckle <jstucklex@ibm.net>

Paul,

Paul Ratcliffe wrote:
<snip> 
> 
> You have conveniently ignored the comment someone else made that there are
> two dereferences in the first line and only one in the second, yet they
> generate the same code. How then can this be if they are of the same type?
> 

Very easily.  Just because the compiler generates the same low level
code on a particular machine doesn't mean the types are the same in the
high level code.

Another example - passing by reference in C++, i.e. 

  foo (int & i)

Under the covers, the compiler generates the same code as if the
function were defined as

  foo (int * i)

but they are NOT the same types!

Low level code != high level code!!!!!
-- 

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

Jerry Stuckle
jstucklex@ibm.net
JDS Computer Training Corp.
Sun Certified Java Programmer
VisualAge/Java Certified Developer
VisualAge/C++ Certified Developer

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

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

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

From: charette@writeme.com                              02-Sep-99 14:38:15
  To: All                                               02-Sep-99 15:03:09
Subj: Re: Pipes( > < | )  do text only?

From: charette@writeme.com

In <7qlqac$qkj$1@nusku.cts.com>, Will Rose <cwr@cts.com> writes:
[...]
>
>Looking back at some old filter code I wrote, I _think_ stdin and stdout
>default to binary under VAC++.  Anyway, here's some sample code I used to
>convert stdout to text mode:

Using C/Set++ (3/1997), I once wrote a cgi-bin that would output a GIF
image to stdout so the web server could redirect it to the client.  It never
worked, until I eventually found the _setmode() function to put stdout into
binary mode instead of the usual text mode.

The default at the time (Warp v3) was text mode, not binary.  I have a
difficult time imagining that IBM would change the default for something
like this -- especially since the other two older PC-based operating
systems, DOS and WinXX, also use text as the default, and many apps
most likely rely on this fact.  BTW, Linux, being Unix-based, not only
uses binary mode for stdout, but doesn't even have a text mode.

Stephane Charette
charette@writeme.com

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

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

From: thannymeister@spambegone.yahoo.com                02-Sep-99 11:45:08
  To: All                                               02-Sep-99 15:03:09
Subj: Re: atoi access exception

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

On Wed, 01 Sep 1999 23:47:48 GMT, Paul Ratcliffe wrote:

>On Wed, 01 Sep 1999 03:00:01 -0400 (EDT), Mike Ruskai
<thannymeister@yahoo.com>
>wrote:
[snip stuff I'm tired of talking about]

>>>void main(void)
>>
>>Void?  A language lawyer using void?!  For shame!
>
>What are you talking about? What's wrong with void? This function takes no
>arguments and returns no value? How the fuck are you supposed to declare it?

void main() is illegal in the ANSI C specification.  The main() function is
to always return an int.


--
 - Mike

Remove 'spambegone' to send e-mail.


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

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

From: eM_evomeR_sdturne@us.ibm.com                      02-Sep-99 17:48:07
  To: All                                               03-Sep-99 03:37:15
Subj: Re: ALP Syntax question

From: eM_evomeR_sdturne@us.ibm.com (Steve Turner)

In <37CD31F5.729D@Leginfo.LBDC.State.NY.US>, Peter Flass
<Flass@Leginfo.LBDC.State.NY.US> writes:
>I'm trying to find the correct syntax.
>I want to call a function indirectly thru a vector table.  Assume EDI
>points to a table of function addresses.  I tried the obvious -
>          CALL 8[EDI] 
>     for example, and ALP generates a warning message -
>   "Warning ALP4501: Assuming NEAR distance for       operand size".
>
>Apparently the correct code is being generated, but the warning is
>annoying.  I tried playing with casting, but can't seem to find syntax
>that works.
>Naturally I'm using ".model flat".
>
>Any assembler gurus out there that can help?  TIA.

Did you check the ALP documentation to see WHY you are getting that error?
It says:

  A CALL or JMP instruction was coded to pass control indirectly through a 
  memory operand of indeterminate size.  When operating in MASM 5.10 
  emulation mode, the memory operand is assumed to have the same size as 
  address size of the segment containing the CALL or JMP instruction, and 
  implies a target having NEAR distance. 

  Recovery:  The memory operand should be given an explicit size, regardless 
  of whether or not the default address size and NEAR distance is the desired 
  operation.  This code will cause assembly errors if not assembled under MASM 

  5.10 emulation mode. 

Coding this:

        CALL dword ptr 8[EDI]

tells the assembler explicitly that the memory to which EDI (plus 8) points is
32-bits in size (16-bits would be the alternative; but you would only specify
WORD PTR if you were doing mixed-model programming).  ALP rarely "assumes"
any kind of default value without warning you about it.

An alternative to using an explicit DWORD PTR override would be to use the
ASSUME directive to tell the assembler that EDI points to a DWORD variable:

        ASSUME EDI: PTR DWORD
        CALL 8[EDI]

Steve Turner, OS/2 Tools Development, IBM, Austin TX.

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

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

From: bert@brothom.nl                                   03-Sep-99 00:50:24
  To: All                                               03-Sep-99 06:09:28
Subj: quick label updates

From: Bert Thomas <bert@brothom.nl>

I'm trying to update the contents of a label in a dialog about 10 times
per second. I'm not satisfied by the result because the label flickers a
lot. Is there a trick to solve this? Or how should it be done the proper
way?

Bert

--- WtrGate+ v0.93.p7 sn 165
 * Origin: Usenet: Cistron Internet Services B.V. (1:109/42)

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

From: jon@smartpeopleinc.com                            03-Sep-99 01:13:04
  To: All                                               03-Sep-99 06:09:28
Subj: a great resource for OS/2 contract, career and infoseekers

From: "Smart People" <jon@smartpeopleinc.com>

A 'new' career, contract and professional resource site for technology
professionals: iSmartPeople.com

Whether your an active career or contract seeker or just keeping your
options open, post your profile with us at http://www.ismartpeople.com and
keep in tune with what OS/2 offers you across North America. Our iSmart
Notification feature will bring the careers or contracts to your attention
that map your skills requirements at the dollars you specify and in the
location(s) of your choice.

iSmart People.com in just a few days will offer our iSmart Center where
Windows/Object and Web developers can share technical problems and solutions
and correspond with your peers across the continent. Through our technical
forums, we will host on going discussion topics such as OO Design and
Development, OS/2 Configuration, Java Development, Web Development, Database
Development, CORBA, Windows Solutions, Linux Web Integration,
Internet/Intranet Integration and e-Commerce integration topics in moderated
forums, where you don't have to worry about unsolicited postings
interrupting professional discussions. (like this one)

See you there,
iSmart People.com
http://www.ismartpeople.com




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

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

From: charette@writeme.com                              03-Sep-99 03:24:21
  To: All                                               03-Sep-99 10:34:21
Subj: nitpicking 

From: charette@writeme.com

In <gunaalzrvfgrelnubbpbz.fhfvrg0.pminews@netnews.worldnet.att.net>, "Mike
Ruskai" <thannymeister@spambegone.yahoo.com> writes:
>On Wed, 01 Sep 1999 23:47:48 GMT, Paul Ratcliffe wrote:

>>>>void main(void)
>>>
>>>Void?  A language lawyer using void?!  For shame!
>>
>>What are you talking about? What's wrong with void? This function takes no
>>arguments and returns no value? How the fuck are you supposed to declare it?
>
>void main() is illegal in the ANSI C specification.  The main() function is
>to always return an int.

Guys...geez...!  This is has gone on for long enough.  Call it quits.  Your
discussions have nothing to do with the atoi() question that had been
posted.  Funny thing is, I don't even remember what the solution was to
the original problem.  All you're doing now is ruffling up each other's
feathers.

Stephane Charette

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

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

From: Flass@Leginfo.LBDC.State.NY.US                    03-Sep-99 09:56:10
  To: All                                               03-Sep-99 17:08:13
Subj: Re: ALP Syntax question

From: Peter Flass <Flass@Leginfo.LBDC.State.NY.US>

Steve Turner wrote:
> Coding this:
> 
>         CALL dword ptr 8[EDI]
> 
> tells the assembler explicitly that the memory to which EDI (plus 8) points
is
> 32-bits in size 

Thanks Steve.
I read the message text, but I was apparently fixated on "NEAR".  It
should have been obvious, but I was trying various invalid expressions
like:
  CALL NEAR PTR 8[EDI], etc.
I'm more of an S/390 assembler programmer, and that's RISC compared to
the variety of instruction and operand formats on Intel.

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

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

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