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: +49-6036-980114 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 ___ * 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 ___ * 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: eddy.thilleman@net.hcc.nl ... 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 ___ * 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 (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 (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 (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 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 (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) +----------------------------------------------------------------------------+ +============================================================================+