
                  OS/2 Programming                 (Fidonet)

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

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

From: Mario Semo                                        05-Dec-99 16:32:26
  To: Fred Springfield                                  11-Dec-99 06:20:20
Subj: Environment Variables

Hallo Fred!

Antwort auf eine Message von Fred Springfield an Mario Semo:

 FS> Thanks for your input.  One of the IBM developers recommended that I
 FS> be sure to put the VACPP dll's after the OS/2 dll'l in the LIBPATH,
 FS> and also the similar thing for the PATH statement, because the OS/2
 FS> stuff is newer.

thats according to what i say. 

 FS> However, I still have a conflict with the SET SOMRUNTIME statement
 FS> which is generated by VACPP and Lotus S/S, and points to different
 FS> directories.

let SOMRUNTIME point to the directory where SOM is loaded from. which in your
case is OS2. (and not Lotus).

here is a old mail regarding this (and one other) envir setting

# 3305 S1/SOMHowTo
    04-Jan-96  21:23:43
Sb #3243-SOMRUNTIME etc.
Fm Ryszard Kwiatkowski 76711,1331
To mario semo 100414,1025

18184 Re: SOMRUNTIME etc.

Mario,

Regarding the

  SET SMCLASSES=WPTYPES.IDL

  SET SOMRUNTIME=F:\IBMCPP\DLL statements you asked about before:

??????????????????????????????????????????????????????????????????????????
  SOMobjects Developer Toolkit Users Guide
  Page B - 1

  The SOM Toolkit supplies a program, ctoi , to assist users
  in converting .csc files to .idl files.  Before running ctoi
  , ensure that the directories containing files to convert
  have all the neces - sary .sc and .psc files already
  created.  (The SOM Compiler can be run with the -ssc and
  -spsc options to create .sc and .psc files from a .csc
  file.)  The conversion process requires a list of all the
  classes used in the files to be converted, so that forward
  references to classes can be handled correctly . Store this
  list of class names in some file (for example, clsfile ).
  The name of this file must be specified to the SOM Compiler
  by the SMCLASSES environment variable:

  For OS/2:
   SET  SMCLASSES=clsfile
  For  AIX:
   export  SMCLASSES=clsfile


  The process of converting .csc files to .idl files requires
  a list of all the classes used in the .csc files so that
  forward references to classes can be handled correctly.
  The list must be stored in a file, and the SMCLASSES
  environment variable establishes the file name when
  ctoi is run.


 I believe the key to SMCLASSES appears to be the phrase
 "forward reference".  I was able to run "ctoi" and successfully
 convert a .csc file to an .idl file with SMCLASSES unset.
 If no forward references are made, the SMCLASSES and the
 associated file contents do not appear to be required.


 Install support for SOM apps Installation/Configuration Guide
 Page 105

 Windows  applications
 Since  SOMobjects is not supplied in the Windows operating system, a base
 reference  point is needed for every application that installs the
SOMobjects
 W orkstation  Enabler run time. On the Windows system, this is determined
from
 the  value of the  SOMRUNTIME  environment variable.

 To  package and install a version of the SOMobjects Workstation Enabler run
 time  for Windows, you must adhere to the following rule:
 The  SOMobjects Workstation Enabler  run time must be loaded from only
 one  place  on the system, and that place is the directory pointed to  by
 SOMRUNTIME .  If the  SOMRUNTIME  environment variable has not  previously
 been  set, the location of the run time is at the discretion of the install
 program.  However , SOMRUNTIME  must be set to  the installed directory
 following  the installation.

????????????????????????????????????????????????????????????????????????????

rlj-18184

Ryszard Kwiatkowski PSP-SOMobjects Technical Support sombug@austin.ibm.com


mario semo, LC/32 Development Team, kirchner SOFT, Vienna, Austria.




Servus, Mario!

--- FleetStreet 1.21 PR#2
 * Origin: LC/32 Development Team, http://www.kirchnersoft.com (2:310/14.11)
251/25

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

From: Mario Semo                                        08-Dec-99 17:00:11
  To: Will Honea                                        11-Dec-99 06:20:20
Subj: Environment Variables

Hallo Will!

Antwort auf eine Message von Will Honea an Fred Springfield:

 WH> That kinda depends of WHICH copy of SOM.IR got put there <g>. 
 WH> Actually, the SET SOMIR= line defines the search order ahead of any
 WH> other path statements.

SOMIR and PATH are completly unrelated. PATH is used from the OS to search for 
applications, while SOMIR is used from the SOM System to search for installed
SOM interfaces (IR=InterfaceRepository).

When someone runs a SOM application  aeh a SOM Development tool, SOM will
modify and or create an existing SOM.IR.

but only the LAST element in the SOMIR search path will be modified. (so its
always a good idea to a have a "dummy" SOMIR as the last element.

When you have "." as part of SOMIR, then these SOM tools will create an empty
(as i remember 32byte) interface repository in the "current" directory
(wherever you app was started from).

This may be a reason, that he has an SOMIR in C:\. 

Heres is my SOMIR: (note: i have installed SOM Toolkit 2.1.4 which is nearly
equal level as SOM in OS2, but has about 500 additional development tools.
thats why i use SOM.IR from f:\).
Normally, all "SOM.IR" should be equal. so it should be enough to have 1
SOM.IR in the SOMIR path. (SOMIR is the interface repository for the SOM
system itself. )

SOMIR=F:\SOM21\ETC\SOM.IR;I:\OS2\ETC\SOM.IR;I:\OS2\ETC\WPSH.IR;I:\OS2\ETC\WPDSE
RV.IR;I:\OS2\ETC\REXX.IR;F:\DUMMY\DUMMY.IR;



Servus, Mario!

--- FleetStreet 1.21 PR#2
 * Origin: LC/32 Development Team, http://www.kirchnersoft.com (2:310/14.11)
251/25

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

From: David Noon                                        10-Dec-99 20:06:12
  To: Ian Moote                                         11-Dec-99 06:20:20
Subj: Facts?

Hi Ian & Murray,

Replying to a message of Ian Moote to MURRAY LESSER:

 IM> Uh... we're not going to start into this "I was flying starships when 
 IM> your grandfather was in diapers" stuff, are we?

[moderating]

That's correct, we aren't.

This thread seems to be getting somewhat inflammatory. It could be a good idea 
either to agree or agree to disagree, ending the thead either way. The
discussion of the Y2K compliance of DOS is marginal, at best, in this echo,
and given the heat that seems to be developing it seems to me that it will be
beneficial to close this thread.

Regards

Dave

Moderator, OS2PROG echo

--- FleetStreet 1.24.1
 * Origin: The man who broke the bank at Monte Carlo (2:257/609.5)
251/25

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

From: Will Honea                                        11-Dec-99 12:12:00
  To: Mario Semo                                        11-Dec-99 12:12:00
Subj: Environment Variables

Mario Semo wrote to Will Honea on 12-08-1999

MS> SOMIR and PATH are completly unrelated. PATH is used from 
MS> the OS to search for applications, while SOMIR is used from 
MS> the SOM System to search for installed SOM interfaces 
MS> (IR=InterfaceRepository).
 
Thanks, Mario.  I knew the PATH and SOMIR were used totally
differently but I hadn't really chased down all the details since the
time I installed Watcom 10.0 and got the SOMIR pointed to the Watcom
copy of the toolkit.  Made life impossible until I finally figured out
what it was.

My comment to Fred was due to some odd/erratic things happening after
about fp10.  I had re-installed VACPP 3.0 and had not checked the SOMIR
statement in config.sys (which I normally do since the Watcom fiasco). 
Sure enough, I had forgotten to change it back. After I changed the
config.sys SOMIR order to put the \os2\etc\som.ir ahead of the VACPP 3
som.ir path.  That got rid of all sorts of irritating things - like
unclosable windows, non-minimizable sessions at times, and a host of
visual builder problems. Apparently, there is a difference between the
Warp 4 SOM level and that included in the VACPP Toolkit. A case of a
little blind luck that worked out, but I'll keep your note on file.  I
was hoping to be able to get to the SOM 3 stuff before long to see if
that's even remotely portable so I'll probably REALLY foul up the SOM
setting a few times.
 
Will Honea <whonea@codenet.net>
--- Maximus/2 2.02
 * Origin: OS/2 Shareware BBS, telnet://bbs.os2bbs.com (1:109/347)


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

From: MIKE RUSKAI                                       11-Dec-99 07:18:00
  To: DAVID VAN HOOSE                                   12-Dec-99 17:15:14
Subj: HPFS

Some senseless babbling from David Van Hoose to Mike Ruskai
on 12-06-99  06:41 about HPFS...

 -> I've been doing some poking around in that area.  I'm currently
 -> seeing if I can't write an undelete that works faster than the one in
 -> GTU 3.0.

 DVH> Cool. Is it possible that you could share your research on
 DVH> the subject? I am wanting to create a boot loader that does
 DVH> everything using sector IO.

I don't think any information I find would help there.  All of my "direct"
sector reads are done via DosDevIOCtl(), which is a high-level interface,
serviced by the base device driver required to operate the device in
question (for IDE drives, IBM1S506.ADD, or a replacement).

A boot loader would undoubtedly use the BIOS to read the drive, to the
point where the base device drivers can be loaded, after which drive access
is performed through said base device drivers (else you get the "OS/2
cannot operate your hard disk" message).

Mike Ruskai
thannymeister@yahoo.com


... And those who lack the courage say its dangerous to try.

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)
382/92

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

From: Jonathan de Boyne Pollard                         04-Dec-99 10:11:21
  To: MIKE RUSKAI                                       13-Dec-99 03:32:21
Subj: Clocked!

 JDBP>> No.  The limits of 32-bit implementations of the C language and the
 JDBP>> C++ language are 2038-01-19 and 2106-02-07, respectively,
 JDBP>> depending from whether the underlying type of `time_t' is signed
 JDBP>> or unsigned.

 JDBP>> The limits of 64-bit implementations of the C language and the C++
 JDBP>> language are somewhat higher.

 MR> This strikes me as something of an understatement.

I gather that the British are famous for that.

 MR> A signed 64-bit integer would make the C timestamp function until the
 MR> universe is about 20 times older than it currently is, long after the
 MR> sun and earth are gone.
 MR>
 MR> Using the same integer as a millisecond counter would last for over
 MR> 292 million years.

Some operating systems use 64-bit nanosecond counters with zero as the start
of the year 1600 (Gregorian).

  JdeBP 

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

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

From: Jonathan de Boyne Pollard                         04-Dec-99 10:11:25
  To: Ian Moote                                         13-Dec-99 03:32:21
Subj: Basic Pds Y2k Ok

 IM> I don't know about you, but I intend to be sending E-Mail to my great-
 IM> great-great grandkids over the Galactinet with my super-conducting 
 IM> berylium parallel processing clone from my summer home on Mars. [:)

Another adherent to the Vila school of philosophy.

 GW>> According to tests run by some of the other echo users the 2079
 GW>> thing is *NOT* a problem with OS/2 itself (by that I mean the base OS
 GW>> resident in memory) but with the support utilities provided with it.

 IM> Well, that distinction may mean something to somebody but like I said,
 IM> I  set my RTC to 2080 and OS/2 came up thinking that it was 1980. To
 IM> my way  of thinking, if there were nothing wrong with the base
 IM> operating system  then there would be no need for date windowing in
 IM> the first place. It  seems pretty obvious to me that while OS/2 won't
 IM> have a problem in the  year 2000, this is only due to a kludge and
 IM> OS/2 has a date problem.

OS/2 doesn't have a date problem, though.  Even in 16-bit OS/2 the year value
in the global infoseg is a 16-bit value that can hold values up until 65535. 
What OS/2 has is a design that is limited of necessity by the underlying PC
hardware.  You are basing your reasoning on the assumption that the RTC
hardware is "good until the year 9999".  It isn't.  It's good for exactly 100
years from any given base year.  In the case of the IBM PC/AT, that base year
is 1980, meaning that it is good until the year 2079.

This is because the majority of RTCs do not have proper century registers (due 
to the somewhat ironic fact that because of windowing fixes in operating
systems and BIOSes, hardware manufacturers have not felt compelled to produce
such chips).  An operating system that wants to work on a wide range of PC/AT
or PS/2 compatiable machines can make *no* assumptions about the location of a 
century byte, nor even assumptions about its presence in the first place.

If there were a way of determining unambiguously that there were a century
byte and where it were stored in NVRAM by the BIOS (and there are at least 3
locations that it can be in), the clock driver in OS/2 would be able to obtain 
the century byte and would not need to include a windowing fix.  But there is
no such way for all of the hardware that OS/2 is targetted to run on.  The
ACPI specification provides a means for operating systems to obtain the
location of the century byte in NVRAM, true, but the ACPI specfication is
relatively new.  Older BIOSes simply won't support it.

  JdeBP 

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

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

From: Jonathan de Boyne Pollard                         09-Dec-99 09:30:04
  To: Rob Basler                                        13-Dec-99 03:32:21
Subj: sendto() doesn't work on

 JDBP>> I find it hard to believe that broadcast doesn't work, too.  (-:
 JDBP>>
 JDBP>> You've checked the basics, haven't you ?  You've checked
 JDBP>> that you've configured a broadcast address for that
 JDBP>> interface in TCP/IP configuration, for example, yes ?

 RB> Unfortunately the TCP/IP configuration notebook doesn't work.  Hasn't
 RB> worked for ages.  Any configuration has to be done manually with the
 RB> configuration files.  When I start the notebook it gives me a java
 RB> null pointer error and quits.

Use the -a option to NETSTAT to see the broadcast address information, then. 
The broadcast IP address for an interface can be set using the `broadcast'
parameter to IFCONFIG in the setup script.

The output from `netstat -s' looks to be as it should, unfortunately, which
rather puts the kibosh on that theory.  The next thing to check is your
routing table, using the -r option.

  JdeBP 

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

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

From: Jonathan de Boyne Pollard                         12-Dec-99 10:40:09
  To: Ian Moote                                         13-Dec-99 03:32:21
Subj: Clocked!

 IM> I'm trying to answer your posts all in a single message. In the
 IM> absense  of some explanation on your part, I'm moving this reply
 IM> _back_ into the  [OS2PROG] conference from where the thread
 IM> originated. If you wish to  move the discussion into another
 IM> conference it is customary on FidoNet  to include a brief explanation
 IM> at the head of the message for the  benefit of the echo participants.

Quoted from the very message that you are replying to above:

JdeBP> I've replied to the non-programming part of your message, where you 
JdeBP> asked about clock chips with proper century registers, in the OS2HW
echo.

  JdeBP 

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

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

From: David Van Hoose                                   13-Dec-99 07:07:00
  To: Mike Ruskai                                       13-Dec-99 21:26:10
Subj: HPFS

-> I don't think any information I find would help there.  All of my
-> "direct" sector reads are done via DosDevIOCtl(), which is a
-> high-level interface, serviced by the base device driver required to
-> operate the device in question (for IDE drives, IBM1S506.ADD, or a
-> replacement).

Damn. Well, can you send me some stuff on the high
level end? It might help me a bit with the basic
idea of how to do it. From there, I can learn how
the BIOS fits into it all. :)

-Dave

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

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

From: MIKE RUSKAI                                       13-Dec-99 11:36:00
  To: DAVID VAN HOOSE                                   14-Dec-99 01:17:12
Subj: HPFS

Some senseless babbling from David Van Hoose to Mike Ruskai
on 12-13-99  07:07 about HPFS...

 -> I don't think any information I find would help there.  All of my
 -> "direct" sector reads are done via DosDevIOCtl(), which is a
 -> high-level interface, serviced by the base device driver required to
 -> operate the device in question (for IDE drives, IBM1S506.ADD, or a
 -> replacement).

 DVH> Damn. Well, can you send me some stuff on the high
 DVH> level end? It might help me a bit with the basic
 DVH> idea of how to do it. From there, I can learn how
 DVH> the BIOS fits into it all. :)

Here's a complete C program that reads the boot sector for drive C:

#define INCL_DOSDEVICES
#define INCL_DOSDEVIOCTL
#define INCL_DOSERRORS
#include <os2.h>
#include <memory.h>
#include <stdlib.h>
#include <stdio.h>

USHORT setHeadCyl(ULONG secNum, PTRACKLAYOUT tl,
                  USHORT trackPerCyl, USHORT secPerTrack);

int main()
{
    PBIOSPARAMETERBLOCK bpb;
    PTRACKLAYOUT tl;
    HFILE driveHandle;
    FILE *sdf;
    PBYTE bpParm, bpData, sdata;
    ULONG bpParmLen, bpDataLen;
    ULONG openAction, openMode;
    APIRET rc;

    /*
        Allocate memory for currently known storage sizes.
    */

    bpb=(PBIOSPARAMETERBLOCK)malloc(sizeof(BIOSPARAMETERBLOCK));
    tl=(PTRACKLAYOUT)malloc(sizeof(TRACKLAYOUT)+sizeof(ULONG));
    bpParm=(PBYTE)malloc(2);
    bpData=(PBYTE)malloc(40);

    if (bpb==NULL || tl==NULL || bpParm==NULL || bpData==NULL)
        {
        printf("\nMemory allocation failure.\n");
        return 1;
        }

    openMode=0;
    openMode=openMode | OPEN_FLAGS_DASD | OPEN_ACCESS_READONLY
                      | OPEN_SHARE_DENYNONE | OPEN_FLAGS_NO_CACHE;

    /*
        Open drive for reading, to get a handle for using with category
        0x08 IOCtl functions.
    */

    rc=DosOpen("C:", &driveHandle, &openAction, 0L, 0L, FILE_OPEN,
               openMode, 0L);

    if (rc!=NO_ERROR)
        {
        printf("\nUnable to open drive C: for reading.\n");
        printf("\nDosOpen() returned %u.\n", rc);
        return 1;
        }

    memset(bpParm, 0, 2);
    memset(bpData, 0, 40);
    bpParmLen=2;
    bpDataLen=40;

    rc=DosDevIOCtl(driveHandle, IOCTL_DISK, DSK_GETDEVICEPARAMS,
                   bpParm, bpParmLen, &bpParmLen,
                   bpData, bpDataLen, &bpDataLen);

    if (rc!=NO_ERROR)
        {
        DosClose(driveHandle);
        printf("\nUnable to retrieve BIOS Parameter Block.\n");
        printf("\nDosDevIOCtl() returned %u.\n", rc);
        return 1;
        }

    memcpy(bpb, bpData, sizeof(BIOSPARAMETERBLOCK));

    sdata=(PBYTE)malloc(bpb->usBytesPerSector);

    if (sdata==NULL)
        {
        DosClose(driveHandle);
        printf("\nMemory allocation failure.\n");
        return 1;
        }

    bpParmLen=sizeof(TRACKLAYOUT)+sizeof(ULONG);
    bpDataLen=bpb->usBytesPerSector;

    tl->bCommand=0;
    tl->usHead=0;
    tl->usCylinder=0;
    tl->usFirstSector=0;
    tl->cSectors=1;

    tl->TrackTable[0].usSectorNumber=setHeadCyl(bpb->cHiddenSectors, tl,
        bpb->cHeads, bpb->usSectorsPerTrack);
    tl->TrackTable[0].usSectorSize=bpb->usBytesPerSector;

    rc=DosDevIOCtl(driveHandle, IOCTL_DISK, DSK_READTRACK, tl,
                   bpParmLen, &bpParmLen, sdata, bpDataLen, &bpDataLen);

    if (rc!=NO_ERROR)
        {
        DosClose(driveHandle);
        printf("\nUnable to read boot sector.\n");
        printf("\nDosDevIOCtl() returned %u.\n", rc);
        return 1;
        }

    DosClose(driveHandle);

    sdf=fopen("bootsect.dat", "wb");

    if (sdf==NULL)
        {
        printf("\nUnable to open sector data file.\n");
        return 1;
        }

    if (fwrite(sdata, bpDataLen, 1, sdf)!=1)
        {
        fclose(sdf);
        printf("\nUnable to write sector data.\n");
        return 1;
        }
    else
        {
        printf("\n%u-byte boot sector written to bootsect.dat\n",
               bpb->usBytesPerSector);
        }

    fclose(sdf);

    return 0;
}


USHORT setHeadCyl(ULONG secNum, PTRACKLAYOUT tl,
                  USHORT trackPerCyl, USHORT secPerTrack)
{
    ULONG secPerCyl=trackPerCyl*secPerTrack;
    ULONG wSecNum=secNum+1;

    tl->usCylinder=wSecNum/secPerCyl;
    tl->usHead=(wSecNum%secPerCyl)/secPerTrack;

    return (USHORT)((wSecNum%secPerCyl)%secPerTrack);
}

Mike Ruskai
thannymeister@yahoo.com


... FBI: Federal Bureau of Intimidation

___ Blue Wave/QWK v2.20
--- Platinum Xpress/Win/Wildcat5! v3.0pr2
 * Origin: FIDO QWK MAIL & MORE!  WWW.DOCSPLACE.ORG (1:3603/140)

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

From: Rob Basler                                        13-Dec-99 22:30:00
  To: Jonathan De Boyne Pollar                          14-Dec-99 05:55:00
Subj: sendto() doesn't work on

JDBP> JDBP>> I find it hard to believe that broadcast doesn't work, too.  (-:
JDBP> JDBP>>
JDBP> JDBP>> You've checked the basics, haven't you ?  You've checked
JDBP> JDBP>> that you've configured a broadcast address for that
JDBP> JDBP>> interface in TCP/IP configuration, for example, yes ?

JDBP>Use the -a option to NETSTAT to see the broadcast address
JDBP>information, then.
JDBP> The next thing to check is your routing table, using the -
JDBP>r option.

Both done, both look fine to me.  I've just made the app print a message
on the console if it is run on Warp Server that you need to add a
command line parameter to specify the server address if you want to run
a LAN game.

Hopefully this will be addressed in the first WSeB fixpack.

Rob.
___
 X SLMR 2.1a X The truth is out there.

--- Maximus/2 3.01
 * Origin: Frog Hollow Port Moody BC 604-469-0264/0284 (1:153/290)
2320/38

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

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