OS/2 Shareware BBS: 15 Message/15-Message.zip/oe991127.zip/Pr991126.txt

Text File | 1999-11-27 | 25KB | 602 lines

                  OS/2 Programming                 (Fidonet)

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

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

From: David Van Hoose                                   20-Nov-99 17:11:00
  To: All                                               20-Nov-99 23:27:09
Subj: Dev'ers Toolkit

HELP! HELP! HELP!

Would anyone here be willing to burn me
a copy of the DevCon CD with the latest
OS/2 Developer's Toolkit on it?
DevCon wants $299 for a subscription,
but I just want that CD.
I am willing to supply money for a CD.

-Dave

--- PCBoard (R) v15.4 (OS/2) 250 Beta
 * Origin: Destiny BBS: 1-850-477-1262 (1:3612/333)

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

From: Thomas Seeling                                    20-Nov-99 12:25:20
  To: All                                               21-Nov-99 06:12:04
Subj: decompiling INF?

Hallo All,


i have lost the source code for INF files of a project. Is there a possibility
to decompile an INF file so that I can enhance and recompile?


Tschau...Thomas

--- GED2 3.0.1
 * Origin: Die TeX-Box: [phone] V.34/X.75 24h (2:2461/332.42)

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

From: Ian Moote                                         20-Nov-99 23:52:00
  To: ALL                                               21-Nov-99 06:57:07
Subj: Basic Pds Y2k Ok

ML> Just shows that MS once was able to do things right!

All the versions of DOS and Windows that I've tested are safe for Y2K,
and all of my documentation implicitely indicates that _all_ versions of
DOS are safe for Y2K.

But this reminds me of a question that I've been meaning to ask. I was
under the impression that all versions of OS/2 were safe for Y2K, but
recently I read an off-hand post elsewhere which indicated that Warp 3
and 4 were only Y2K "ready" after certain fixpack levels.

Note that I shy away from the word "compliant". "Compliant" implies a
standard of some kind. What I want to know is, are there any versions of
OS/2 which are going to bomb or report incorrect dates beginning 01
January 2000?

TIA. Take care and TTYL.

---
 ■■ Unicorns aren't mythical -- virgins are!

--- AdeptXBBS v1.11y (FREEWare/2)
 * Origin: Moote Pointe (1:2424/140)

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

From: Francois Thunus                                   20-Nov-99 23:51:00
  To: Murray Lesser                                     21-Nov-99 21:30:15
Subj: rexx

Hello Murray!

19 Nov 99 21:53, Murray Lesser wrote to Fred Springfield:

 ML>     REXX is a great programming tool for quick and dirty jobs, or even
 ML> for jobs that spend most of their activity manipulating text files, but
 ML> I would not use it as a complete substitute for BASIC PDS, even though
 ML> there are things that are easier to do in REXX than in any other
 ML> language that I know: anything that "needs" the REXX PARSE statement.

fyi:

>----- Begin -----

REXX2EXE.ZIP              202K 11-20-99
 Free rexx "compiler" (generates .EXE from .CMD).
http://www.os2bbs.com/file_d/rexx/REXX2EXE.ZIP

>-----  End  -----

just in case :-)

                             -= Francois =-
                      Francois(at)telematique(dot)org
                       http://www.telematique.org/ft

....context...

--- GoldED 3.0.1
 * Origin:  Xara Sto Pragma ! Gasperich - Luxembourg -> (FidoNet 2:270/25.2)

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

From: Murray Lesser                                     22-Nov-99 11:20:01
  To: Ian Moote                                         22-Nov-99 11:20:01
Subj: Basic Pds Y2k Ok

(Excerpts from a message dated 11-20-99, Ian Moote to All)

Hi Ian--

    You should note that my tests of BASIC PDS compilled for DOS were
made in a Warp 4 VDM.  The "system clock" in a VDM is not the same as
the DOS system clock when the system is booted from real DOS.

IM>All the versions of DOS and Windows that I've tested are safe for
  >Y2K, and all of my documentation implicitely indicates that _all_
  >versions of DOS are safe for Y2K.

    You must have tested on new hardware.  DOS and the DOS-based
versions of Windows use the BIOS driver for the real-time clock, and old
hardware has a bug in its RTC BIOS.  Without an add-on software fix for
the machine's BIOS, the century value for the RTC will not turn over on
1/1/2000.  PC's built after about 1996 (depending on maker) have a
corrected BIOS.  When DOS boots, it sets its own clock from what the
BIOS reads from the RTC.  If you have the buggy BIOS, the DOS clock
comes out wrong after 12/31/1999.  If you just let the system dribble
past 12/31/1999, the DOS system clock will not show an error until next
time you reboot DOS.  It is only when you shut down and reboot that you
will find out whether or not you have the BIOS bug.  AFAIK, the only
version of DOS that contains this software BIOS fix within it is IBM's
PC DOS 2000.  I don't know which, if any, Windows updates fixed this
hardware bug, but if I wanted to guess, I'd guess only the recent Win98
"2nd release."

IM>But this reminds me of a question that I've been meaning to ask. I
  >was under the impression that all versions of OS/2 were safe for
  >Y2K, but recently I read an off-hand post elsewhere which indicated
  >that Warp 3 and 4 were only Y2K "ready" after certain fixpack
  >levels.

    The basic OS/2 operating system (at least since Warp 3) takes care
of "buggy BIOS" machines, and the OS/2 system clock (which is the RTC,
not a separate set of counters) will not die until the end of 2079 ("end
of time" for OS/2 as presently written).  However, some of the add-ons
that are furnished with OS/2 had Y2K errors; most likely those
applications presenting dates with two-digit years.  For example: the
bug in the REXX STREAM() function was "fixed" in Warp 4 FixPak 5
(thereby adding new problems), and further repairs (workarounds for the
problems introduced in FixPak 5) were made in Warp 4 FixPak 6.  I backed
off from FixPak 6 for other reasons, and am happily running under Warp 4
FixPak 5.  I haven't found any further Y2K bugs, but that is not to say
that there aren't any.

IM>Note that I shy away from the word "compliant". "Compliant" implies a
  > standard of some kind. What I want to know is, are there any
  >versions of OS/2 which are going to bomb or report incorrect dates
  >beginning 01 January 2000?

    IBM has announced that OS/2 2.x will never be updated to be "Y2K
compliant" (whatever that means).  I have never tested the system clock
under 2.x, so can not answer that question.  However, there is an IBM
Web site that might answer your questions:
          http://www.ibm.com/software/year2000/alert/

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * If you are not confused, you don't understand the
situation

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


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

From: Murray Lesser                                     22-Nov-99 11:24:02
  To: Francois Thunus                                   22-Nov-99 11:24:02
Subj: rexx

(Excerpts from a message dated 11-20-99, Francois Thunus to Murray
Lesser)

Hi Francois--

FT>19 Nov 99 21:53, Murray Lesser wrote to Fred Springfield:

 ML>     REXX is a great programming tool for quick and dirty jobs, or even
 ML> for jobs that spend most of their activity manipulating text files, but
 ML> I would not use it as a complete substitute for BASIC PDS, even though
 ML> there are things that are easier to do in REXX than in any other
 ML> language that I know: anything that "needs" the REXX PARSE statement.

FT>fyi:

>----- Begin -----

FT>REXX2EXE.ZIP              202K 11-20-99
  > Free rexx "compiler" (generates .EXE from .CMD).
  >http://www.os2bbs.com/file_d/rexx/REXX2EXE.ZIP

>-----  End  -----

FT>just in case :-)

    Thanks, but no thanks.  The one I have (VisPro REXX) merely embeds
the REXX program (with the VisPro GUI DLLs) in an EXE file, but it still
runs under the interpreter.  The main purpose of "burying" the CMD file
in an EXE is to make it harder (but not impossible) for the recipient of
the program to read the source code.  Since I am the "recipient" and
already have the source code, this subterfuge serves me no useful
purpose.

    From the description you sent (and from the name of the program) I
would assume that REXX2EXE does the same thing.  Besides, for ex-BASIC
applications using the equivalent of BASIC's PRINT USING (or formatted
output to a printer), it is easier to write them in PL/I than in REXX.

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * Old engineering adage: there is more than one way to skin
a cat

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


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

From: Ian Moote                                         23-Nov-99 12:44:00
  To: MURRAY LESSER                                     23-Nov-99 18:38:28
Subj: Basic Pds Y2k Ok

ML> IM>All the versions of DOS and Windows that I've tested are safe for
ML> >Y2K, and all of my documentation implicitely indicates that _all_
ML> >versions of DOS are safe for Y2K.
ML>
ML> You must have tested on new hardware.  DOS and the DOS-based
ML> versions of Windows use the BIOS driver for the real-time clock, and
ML> old hardware has a bug in its RTC BIOS.

Perhaps I should clarify my question here. [:) I'm far less concerned
with RTC roll-over as I am with whether the O/S will be able to
accurately report dates beyond 31 December 1999. [:) Do you know of
_any_ versions of OS/2 which will have trouble doing that?


ML> Without an add-on software fix for the machine's BIOS, the century
ML> value for the RTC will not turn over on 1/1/2000. [...] It is only
ML> when you shut down and reboot that you will find out whether or not
ML> you have the BIOS bug.

I've no wish to begin a thread/discussion or to argue with you, but just
for the sake of expressing a point of view, I disagree with the point of
view of there being a "bug" in so-called "older hardware". My point of
view here is that since the limitations of the RTC were well-known at
the time it was implemented into the AT, and that since this limitation
was well-known to those who implemented the BIOS, and that since both
the RTC and the BIOS are both performing exactly the way that they are
intended and expected to, that there is no "bug".

JMO. [:)


ML> The basic OS/2 operating system (at least since Warp 3) takes care
ML> of "buggy BIOS" machines, and the OS/2 system clock (which is the
ML> RTC, not a separate set of counters) will not die until the end of
ML> 2079 ("end of time" for OS/2 as presently written).

Is this true of _all_ versions of OS/2, that they all use the RTC for
for their TOD clock? (Is the 2079 a C thing?)


ML> However, there is
ML> an IBM Web site that might answer your questions:
ML> http://www.ibm.com/software/year2000/alert/

Thanks for the tip. Take care and TTYL.

---
 ■■ Upgraded my network last night.  I bought new Nikes!


--- AdeptXBBS v1.11y (FREEWare/2)
 * Origin: Moote Pointe (1:2424/140)

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

From: Eddy Thilleman                                    22-Nov-99 13:50:14
  To: Jonathan De Boyne Pollard                         23-Nov-99 20:10:11
Subj: PROMPT $I in PMCMD

Hello Jonathan,

16 Nov 99 13:48, Jonathan de Boyne Pollard wrote to Harald Pollack:

JP> I'm looking for a solution that is 32-bit.  Therefore I'm looking for
JP> a solution that uses the ordinary 32-bit Presentation Manager API.
JP> There must be an efficient way of drawing fixed-width text in multiple
JP> colours using the GPI.

Have you thought about DIVE?

I haven't looked at DIVE myself, and I don't know if DIVE would be a help.

  Greetings   -=Eddy=-        email: [e-mail]

... Breaking Windows isn't just for kids anymore!
--- GoldED/2 3.0.1
 * Origin: Windows95 is a graphic DOS extender (2:500/143.7)

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

From: Murray Lesser                                     24-Nov-99 20:06:00
  To: Ian Moote                                         24-Nov-99 20:06:00
Subj: BIOS Y2k Bugs

(Excerpts from a message dated 11-23-99, Ian Moote to Murray Lesser:
original topic: BASIC PDS Y2K OK)

Hi Ian--

IM>Perhaps I should clarify my question here. [:) I'm far less concerned
  > with RTC roll-over as I am with whether the O/S will be able to
  >accurately report dates beyond 31 December 1999. [:) Do you know of
  >_any_ versions of OS/2 which will have trouble doing that?

    AFAIK, if all you are interested in is whether or not OS/2 will
"accurately report dates beyond 31 December 1999" from the system clock
(not necessarily file dates), you will have no trouble with Warp
versions 3 or 4 through December 31, 2079.  I cannot speak for OS/2 2.x
because I never tried it when running those versions.  (There was a bug
in the early OS/2 2.0 CLOCK1$ driver that was fixed in the first CSD.)
The same trouble-free situation will not necessarily be true when you
ask REXX in some OS/2 versions to report file dates past 1999.  That is
where the OS/2 Y2K bugs I know of were.  As I said, there may have been
others.

ML> Without an add-on software fix for the machine's BIOS, the century
ML> value for the RTC will not turn over on 1/1/2000. [...] It is only
ML> when you shut down and reboot that you will find out whether or not
ML> you have the BIOS bug.

IM>I've no wish to begin a thread/discussion or to argue with you, but
  >just for the sake of expressing a point of view, I disagree with the
  >point of view of there being a "bug" in so-called "older hardware".
  >My point of view here is that since the limitations of the RTC were
  >well-known at the time it was implemented into the AT, and that
  >since this limitation was well-known to those who implemented the
  >BIOS, and that since both the RTC and the BIOS are both performing
  >exactly the way that they are intended and expected to, that there
  >is no "bug".

    You don't need to "begin a thread/discussion" because most of us
have been there, done that, on the OS2 echo about two years ago.  This
post will be my last word on the subject.

    Why (when booted from a DOS 5 floppy) does my vintage-1993 IBM PS/VP
show the "rollover" date bug, while my vintage-1997 IBM ThinkPad
doesn't?  Obviously, something was changed in IBM's BIOS design between
1993 and 1997 (and, from previous Fido discussions, in the clone BIOS
designs at about the same time).  If you had an "old" machine (which,
apparently, you don't), you could try (under real DOS) to reset the RTC
to a date after 12-31-1999, reboot, and see what date you get back :-(.
The advertising for the current-version IBM PC-DOS 2000 claims: "It will
automatically correct the date returned by BIOS on many machines that
have 'century rollover' exposure."  If this isn't an easily-fixed design
error dating from AT days (a typical Y2K bug) that wasn't noticed until
comparatively recently, what is it?

ML> The basic OS/2 operating system (at least since Warp 3) takes care
ML> of "buggy BIOS" machines, and the OS/2 system clock (which is the
ML> RTC, not a separate set of counters) will not die until the end of
ML> 2079 ("end of time" for OS/2 as presently written).

IM>Is this true of _all_ versions of OS/2, that they all use the RTC for
  > for their TOD clock? (Is the 2079 a C thing?)

    No, the 2079 "end of time" is not a "C thing" and all versions of
OS/2 (at least since v 2.0) use the RTC for a system clock (see the
description of the CLOCK$ driver in the IBM OS/2 2.0 Technical Library
manual "Physical Device Drivers").  The 2079 limitation is a consequence
of handling the shortcomings of the RTC chip by using a "windowing"
technique, and doesn't have anything to do with what language that
portion of OS/2 might have been written in, although it probably was
written in assembly language for performance reasons.  (Programmers with
any sense do not write device drivers in C, although it can be done!)

    OS/2 doesn't use the hardware BIOS once booting is well under way,
thereby avoiding any BIOS CLOCK$ errors.  I surmise (JdeBP probably
knows) that the OS/2 CLOCK$ drivers read only the two low-order digits
of the RTC clock year, and effectively put the two upper digits into the
CMOS "century byte" by using windowing:  Any year shown as greater than
79 gets 19 in that byte; any year less than 80 gets 20.  If, under OS2,
you attempt to set your system date from the command line to 1-1-2080
(or later) you will get a reply that "the system cannot accept the date
entered."  This comes from an error 327 (Date or time invalid) response
to the OS/2 API call DosSetDateTime().

    It would appear that the BIOS "fix" in my ThinkPad also works by
windowing (I can't conceive of how it would work any other way, other
than to substitute an entirely different non-compatible RTC chip).  If I
boot DOS 5.0 from a floppy, reset the date to 1-1-2000, and reboot, I
get back 1-1-2000 for the date.  If I set the date to 1-1-2080 and then
reboot, I get back 1-1-1980!  Unfortunately, at least for DOS 5, it
doesn't bother to warn me that 1-1-2080 is an unacceptable date :-(. You
might try this experiment on your "Y2K error free" later versions of
DOS/Windows and see what you get.

    Regards,

        --Murray
<Team PL/I>
___
 * MR/2 2.25 #120 * Nothing is so uncommon as common sense

--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


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

From: Ian Moote                                         25-Nov-99 22:57:00
  To: MURRAY LESSER                                     26-Nov-99 03:58:15
Subj: BIOS Y2k Bugs

ML> This post will be my last word on the subject.

I see. Well; I was preparing a reply but I guess I'll just thank you for
your reply and hope that someone else will step up to answer my
question.


ML> If this isn't an easily-fixed design error dating from AT days (a
ML> typical Y2K bug) that wasn't noticed until comparatively recently,
ML> what is it?

Oh I think I was very clear when I said that I had no wish to open this
topic. I've had this discussion enough times to conclude that:

1) People suddenly have a _very_ flexible definition of "bug" when it
comes to discussing Y2K, especially as it applies to the BIOS, and

2) People will believe whatever the heck they like, regardless of what
you can prove or disprove or how reasonable you are. [:)

So thanks anyway. Take care and TTYL.

---
 ■■ Use your wit to amuse, not abuse!

--- AdeptXBBS v1.11y (FREEWare/2)
 * Origin: Moote Pointe (1:2424/140)

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

From: Jonathan de Boyne Pollard                         18-Nov-99 09:39:08
  To: Charles Gaefke                                    26-Nov-99 12:58:17
Subj: Watcom C++ 11.0 and thunking

 JD>> Thanks for your 1998 posting on the powersoft news server, by the
 JD>> way.  I s ages trying to find out why some assembly language code
 JD>> that I wrote to thu from 32-bit to 16-bit wasn't working.  Then I
 JD>> turned up your posting where  noted that

 CG>     Using Watcom 11.0 I take it? :)

As per the subject line, yes.  (-:

 CG> It's a shame Powersoft never fixed Watcom.  10.6 is great.  11.0
 CG> is broke.  11.0a is better, but still broke (atleast for OS/2).

I'm using 11.0b .  Or, rather, I'm using the 11.0b linker.

I vaguely recall having some problems with aliases with the Watcom linker a
year or so ago, but I cannot remember which version that was.  It was probably
10.5 .

 » JdeBP «

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

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

From: Jonathan de Boyne Pollard                         18-Nov-99 09:45:26
  To: MIKE RUSKAI                                       26-Nov-99 12:58:17
Subj: "Paging Peter Knapper! ..

 JDBP>> runs of zero bytes.  LX executables generally do not.  (I say
 JDBP>> "generally", because if they use Watcom C/C++ the linker doesn't
 JDBP>> support compression, alas.  This is a deficiency in Watcom's
 JDBP>> linker, and an unfortunate example of the "jack of all trades,
 JDBP>> master of none" adage.)  This is, of course, visible in the
 JDBP>> comparative sizes of Win32 and 32-bit OS/2 executables.

 MR> FYI, folks, one needn't rely on the compression abilities of a linker
 MR> in OS/2 to compress an executable.
 MR>
 MR> There's a utility called LxLite which you can use to compress or
 MR> recompress an executable.

Since I use the Watcom linker myself, I'm interested.  Where ? Hobbes ? DevCon
?

 » JdeBP «

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

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

From: Jonathan de Boyne Pollard                         18-Nov-99 12:39:16
  To: Rob Basler                                        26-Nov-99 12:58:17
Subj: sendto() doesn't work on WSeB

 RB>      /* Bind the UDP socket to the server address. */
 RB>      client.sin_family      = AF_INET;    /* Server is in Internet Domain
*/
 RB>      client.sin_port        = 0;          /* Any port in a storm */
 RB>      client.sin_addr.s_addr = INADDR_ANY; /* Server's Internet Address
*/
 RB>      if (bind(s, (struct sockaddr *)&client, sizeof(client)) < 0) {
 RB>          return(-1);
 RB>      }

What that is actually doing is binding an address to the *local* end of the
socket, not the remote end.  Your comments are wrong.

Given the address that you are binding to the client end, I have to ask:  Is
it the *server* end that is receiving the "no route to host" errors ?

 » JdeBP «

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

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

From: Jonathan de Boyne Pollard                         20-Nov-99 10:06:16
  To: Tobias Ernst                                      26-Nov-99 12:58:17
Subj: 32-bit console API

 JdBP>> Better yet, I have also written a proper, 32-bit, Unicode, console
 JdBP>> API, CONCALLS.DLL, and a <bsecon.h> header.

 TE> This is really fine. Where can one get this?

I haven't packaged it up properly and uploaded it anywhere yet.  If I have
time this weekend, I shall do.

 » JdeBP «

--- FleetStreet 1.22 NR
 * Origin: JdeBP's point, using Squish <yuk!> (2:257/609.3)

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

From: Ian Moote                                         26-Nov-99 12:13:00
  To: ALL                                               26-Nov-99 16:21:15
Subj: Y2K question.

I asked this question in the [OS2] conference, but nobody there seems to
know the answer. It's a Y2K question and I _thought_ it was pretty
simple:

Is there _any_ version of OS/2 which will not report dates correctly
after 31 December 1999?

Nota bene: I am not concerned with the number of date digits displayed
by some shell, file manager, or other application. I am likewise not
concerned with any so-called BIOS date "bugs", real or imagined, or the
alleged age of my hardware. I am _solely_ concerned with the date
information as returned by OS/2 API's from _any_ version of OS/2.

TIA.

---
 ■■ Useless laws weaken necessary laws.

--- AdeptXBBS v1.11y (FREEWare/2)
 * Origin: Moote Pointe (1:2424/140)

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

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