
                  OS/2 Programming                 (Fidonet)

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

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

From: Jonathan de Boyne Pollard                         09-Sep-99 00:45:01
  To: LEE ARONER                                        11-Sep-99 06:18:08
Subj: TAUCMD

 LA> Johnathan, I'd be interested, but my current state of knowledge    
 LA> of OS/2 programming (Expert DOS, so-so at Win32), might make for    
 LA> a significant latency in useful feedback...probably not what you    
 LA> are looking for.

If you want to have a go despite that, contact Andy Roberts (1:109/921.0) and
get him to add you to the TAUCMD echo/mailing list.  The distribution archive
now contains the first drafts of the C/C++ headers and the import library, and 
also the DLL.  There's still a lot of polishing to be done, and I have yet to
write the documentation.  (Although the header doesn't contain *that* many
functions.)

The same simple conditions apply as for the pre-release testing of OS2CLU: 
You may not make the pre-release publically available or distribute it.  I
don't want pre-releases "escaping" into general circulation.

  JdeBP 

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

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

From: Ian Moote                                         11-Sep-99 11:41:00
  To: HARALD POLLACK                                    11-Sep-99 15:26:19
Subj: Maximum threads.

HP> Servus Ian!

Servus! (I've had more E-Mail from Deutschland in the past week than I 
think I've had in my entire life!)


HP> Nothing 'complex', just simply type 'HELP THREADS' on your command
HP> prompt...

Y'know, I shoulda known that. It seems like nearly _everything_ can be 
reached through the help utility! [:)

Servus, Harald, and take care.

---
  This reader has been unregistered since the big bang...                    
    

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

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

From: Ian Moote                                         11-Sep-99 11:41:00
  To: EDDY THILLEMAN                                    11-Sep-99 15:26:19
Subj: Maximum threads.

ET> Don't forget the THREADS= statement in config.sys (which maximum is
ET> 4095).

Yep -- noted from previous replies but thanks for the reminder. Take 
care and TTYL.

---
  This service is not a safe alternative to having a real life               
         

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

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

From: Jonathan de Boyne Pollard                         10-Sep-99 01:19:19
  To: Eddy Thilleman                                    12-Sep-99 06:23:24
Subj: TAUCMD

 JdBP>> I'm writing an interpreter "engine" for command scripts (a.k.a. 
 JdBP>> "batch files").  The idea is that one can link CMDAPI.DLL into 
 JdBP>> one's application and run command scripts and execute command 
 JdBP>> lines in the context of the current process.
 JdBP>> 
 JdBP>> [...]
 JdBP>> 
 JdBP>> I can see a wide variety of uses for such an API, from NC clones and 
 JdBP>> YAOS variants that no longer need to "shell out" to run commands, to 
 JdBP>> novel approaches to specliased command interpreter programs, such as
 JdBP>> NSLOOKUP or an FTP client, giving them the scripting, redirection,
 JdBP>> environment variable expansion, and pipelining abilities that they 
 JdBP>> so often lack because their own interpreters are comparatively 
 JdBP>> primitive.  [...]

 ET> I'm curious, what advantages has this above REXX ?

Advantages apart from the fact that the REXX interpreter interprets a
*completely different language* and so isn't suitable for any of the tasks
listed in the examples above ?

If one is writing an application that needs to execute command lines, up until 
now one had only two options:  one could "shell out" and spawn a child command 
interpreter process to handle command lines, or one could hand-roll one's own
command interpreter.  Choosing to shell out leads to difficulties with
commands such as SET, PROMPT, and CD not appearing, to the user, to operate
correctly.  Choosing to hand-roll one's own command interpreter is expensive
on the other hand, and often such command interpreters are limited in
function.  Look at most command-driven FTP clients, for example.  They appear
and behave like a command line, issuing a prompt and responding to commands,
but they often lack even the most basic things, like the ability to redirect
the output of commands to file, the ability to combine commands into pipelines 
or to execute multiple commands on a single line, or the ability to use
environment variables in command lines.

With my CMD interpreter engine an application developer now has a third
option: use the interpreter engine to interpret commands.  The engine provides 
a complete implementation of the CMD language, which has benefits to the
developer and to the user.  The developer doesn't have to hand-roll their own
command interpreter at all or hand-roll their own built-in versions of
standard commands such as SET and CD, and the user gains from the fact that
*all* of the features of the standard command interpreter are now present and
available for use if needed.

  JdeBP 

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

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

From: Eddy Thilleman                                    11-Sep-99 22:09:26
  To: Thomas Seeling                                    12-Sep-99 22:02:13
Subj: os/2 in teller machines

Hallo Thomas,

Op 07-09-99 08:18 schreef je aan Eddy Thilleman:

TS> if we're going to nitpick, it is a "Wurst" (sausage). 

Oops, I didn't see that error. :)

TS> There are a lot of regional specialties from all over Germany.

I hadn't thought about the German speciality: Wurst (in all kinds and sizes?). 
:)

TS> Personally I prefer Bratwurst at barbequeue :)

That must be nice. :)

TS> Most teller machines are using OS/2 to handle your money requests :).

I use OS/2 to view Wurste on my screen. ;-)

  Groeten   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

---
 * Origin: Speedy Gonzales  (2:500/143.7)
102

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

From: LEE ARONER                                        12-Sep-99 05:59:00
  To: JONATHAN DE BOYNE POLLARD                         13-Sep-99 09:18:25
Subj: TAUCMD

 LA> Johnathan, I'd be interested, but my current state of knowledge    
 LA> of OS/2 programming (Expert DOS, so-so at Win32), might make for    
 LA> a significant latency in useful feedback...probably not what you    
 LA> are looking for.

JDBP> If you want to have a go despite that, contact Andy Roberts
(1:109/921.0) and
    > get him to add you to the TAUCMD echo/mailing list.  The distribution
archive
    > now contains the first drafts of the C/C++ headers and the import
library, and
    > also the DLL.  There's still a lot of polishing to be done, and I have
yet to
    > write the documentation.  (Although the header doesn't contain *that*
many
    > functions.)

JDBP> The same simple conditions apply as for the pre-release testing of
OS2CLU:  You
    > may not make the pre-release publically available or distribute it.  I
don't
    > want pre-releases "escaping" into general circulation.


   Agreed and done.

                                               LRA


 -- SPEED 2.01 #2720:  GPF - the Microsoft Award for Programming Excellence..
--- Platinum Xpress/Win/Wildcat5! v2.0
 * Origin: Memory Alpha - (253) 859-6200 (1:343/311)

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

From: Eddy Thilleman                                    13-Sep-99 15:34:29
  To: Jonathan de Boyne Pollard                         14-Sep-99 15:31:09
Subj: TAUCMD

Hallo Jonathan,

Op 10-09-99 01:19 schreef je aan Eddy Thilleman:

...snip...

JdBP> file, the ability to combine commands into pipelines or to execute
JdBP> multiple commands on a single line, or the ability to use
JdBP> environment variables in command lines.

...snip...

JdBP> features of the standard command interpreter are now present and
JdBP> available for use if needed.

Forgive if I'm mistaken, but doesn't offer the REXX interpreter that too?
There are programs that can be controlled from a REXX file (ZOC is one example 
which comes to mind).

  Groeten   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

---
 * Origin: Speedy Gonzales  (2:500/143.7)
102

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

From: Thomas Seeling                                    13-Sep-99 12:36:15
  To: Mario Semo                                        14-Sep-99 20:30:17
Subj: ... Perl

Hallo Mario,

Am 08 Sep 99 um 10:53 schrieb Mario Semo an Thomas Seeling:

 TS>> There sure is, the first winner was a cow-orker of mine who submitted
 TS>> this:
to clarify: I have this from the Usenet, it was not me who got it from his
cowork.er

 >> *_=\$#;$/=q#(.)#;$#=10;$^X=~s|.*/||;$\=chr;$#=gmtime$#;substr($#,$^F#^F
 >> *$^F**$^F-1)=al;s$\$/( )\$/\$/$e\$2\u\$^X\$2\$3o\$1r$&&print time

 MS> syntax error at x.pl line 2, near "F "
your quote contained an error. Above is the corrected, working version.
Use sed -e s!';'!';\n'!g to make it more readable and look up the special
variables like $/, $\, $^F etc.

=== Cut perl.txt ===
tfx404:/home/root/tivoli # perl ./x.pl
The Perl Journal
tfx404:/home/root/tivoli # perl -v

This is perl, version 5.003 with EMBED
        built under aix at Jan  7 1997 17:39:32
        + suidperl security patch

Copyright 1987-1996, Larry Wall

Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.

tfx404:/home/root/tivoli # uname -a
AIX tfx404 1 4 000127738900
=== End perl.txt ===


Tschau...Thomas

--- GEDW32 3.0.1
 * Origin: Die TeX-Box: +49-6036-980114 V.34/X.75 24h (2:2461/332.42)

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

From: David Van Hoose                                   13-Sep-99 12:57:00
  To: Sean Dennis                                       15-Sep-99 06:35:05
Subj: ... Perl

TS>>> *_=\$#;$/=q#(.)#;$#=10;$^X=~s|.*/||;$\=chr;$#=gmtime$#;substr($#,
TS>>> $^F#^ F *$^F**$^F-1)=al;s$\$/(
TS>>> )\$/\$/$e\$2\u\$^X\$2\$3o\$1r$&&print time

SD>>> What in God's name does that do? :P

AG>> I don't know, but if you rot(13) it, it is still not clear!

SD> Heheh-that's bad... ;)

Looks to me like a drunk trying to program blindfolded. :)
What does the rot(13) do?

-Dave

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

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

From: Vitus Jensen                                      05-Sep-99 19:47:22
  To: MIKE RUSKAI                                       15-Sep-99 12:25:20
Subj: Terminating threads clean

Hi MIKE,

30.08.99 00:43, MIKE RUSKAI wrote a message to VITUS JENSEN:

 MR> [snip]
 MR>> I don't know what other resources that would need to be
 MR>> recovered from a thread.  As far as I can figure, a thread
 MR>> should release any resources it's using by itself.

 VJ>> The only resource DosWaitThread() could release is the exit code
 VJ>> of the thread it waited for.  Obviously this information has to
 VJ>> be stored somewhere outside of the died thread.  Writing another
 VJ>> test program ... No, there is no difference between starting
 VJ>> 200000 threads with and without DosWaitThread.  Either OS/2 uses
 VJ>> a fixed size table or the amount of storage is to small to get
 VJ>> noticed.

 MR> I just looked over the CP reference, and it was never stated
 MR> (even implicitly) that DosWaitThread() *should* be called to
 MR> recover resources. It was presented only as an option.  And it is
 MR> also explicitly stated that the thread information block is
 MR> maintained by the operating system.  That's the only memory
 MR> allocated for each individual thread, apparently, and if OS/2
 MR> relied on DosWaitThread() to release that storage, the result
 MR> would be a big memory leak.

So my memory may refer to some other OS with thread support (NetWare or
WinXy).


 MR> My best guess is that OS/2 keeps a static array that indicates
 MR> whether the thread ID is occupied, and holds a pointer to the TIB
 MR> (and an indicator to which process ID it belongs).  My
 MR> speculation beyond that is that when threads of a process are
 MR> terminated, the process ID indicator remains intact, as well as
 MR> the TIB storage.  When new threads are started, they are first
 MR> given ID's that are not associated with any running processes,
 MR> and when they are exhausted, begins recycling thread ID's that
 MR> were previously used in the current process, and overwrites the
 MR> TIB information. At process end, all TIB structure storage for
 MR> the process is released, and process ID associations removed.  

(refering to OS/2 Debugging Handbook Vol 4)
There is a linked list of Thread Control Blocks (TCB) in the Per Task Data
(PTDA).  There seems to be a difference between /active/ and not so active
TCBs.
A TCB holds a pointer to TIB (which doesn't contain an exit code as you wrote) 
and a ptr to an Thread Swappable Data (TSD).  This TSD holds a field called
/TSDulExitCode/ ("proposed Thread Exit Code").


 MR> If my guess is correct (or nearly so), then there's no guarantee
 MR> that the information in the TIB and TIB2 will remain valid after
 MR> the thread has terminated, and before DosWaitThread() is called. 
 MR> Of course, I don't see anything in that structure that's useful
 MR> after the thread has ended, anyway.  If all thread ID's have TIB
 MR> and TIB2 storage associated with them, that'd be only 160K of
 MR> memory, which isn't very noticeable on the whole.

TSDs are allocated in the system arena (above 512MB) so more or less allocated 
TSDs can't be noticed by looking at the available adress space for user
processes.  Unfortunately my machine has enough swap space so it can't be
noticed by looking at the available memory.  Even the /resident/ memory won't
grow as TSDs are swapable.
I think one needs something like Theseus to detect any changes.


...
 MR> Finally, I may be missing something, but I don't find anywhere
 MR> for a thread to provide a return code, save in a structure
 MR> pointed to by the thread's argument, which must be maintained by
 MR> the application.

?  I don't understand: do you think about something more than the value passed 
to return?

C-x C-s
    Vitus

--- Sqed/rexx 440:
 * Origin: Those who can, do.  Those who can't, supervise! (2:2474/424.1)

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

From: Vitus Jensen                                      05-Sep-99 21:11:23
  To: Ian Moote                                         15-Sep-99 12:25:20
Subj: Maximum threads.

Hello Ian,

02.09.99 07:20, Ian Moote wrote a message to ALL :

 IM> I'm writing for Warp 4. How many threads can be started by a
 IM> single process? Unblocked. Real world, not theoretically.

/Unblocked/ means it's a simple mathematical expression depending on TIMESLICE 
and MAXWAIT settings:
The defaults are 32ms timeslice and 3s MAXWAIT.  That means that as long as
you keep the thread count below 3000/32 = 93 every thread will get it's share
of CPU time.  If you increase the thread count some threads won't (and
starvation boosts will play with priorities).

 IM> I know that this is probably a simple question with a complex
 IM> answer, so feel free to be as long-winded and technical as you
 IM> like. [:)

If you don't mind any uneven distribution of CPU time see this post:

========<start>=======================================
(OS2PROG, Will Honea to Darin McBride, 24.06.99 02:05)

Darin McBride wrote to Will Honea on 06-23-1999


DM>  WH> Especially when the limit is what, 4096 max?

DM> Good point.  I didn't even bother to look that up.  It seems to be
DM> 4095,  actually.  Probably one reserved for system use.

DM> That said, I also noticed that if you don't specify a 
DM> THREADS= line in your config.sys, it defaults to 64.  Could 
DM> anyone explain to me why that is STILL the default?  :-)  I 
DM> dunno about anyone else, but I have 55 processes and 188 
DM> threads going, and my system is relatively quiet.  64 would 
DM> have killed my system ages ago.  I can understand OS/2 1.0 
DM> running on a 286 having that default, but Warp 4?  Silly.


Funny how these topics seem to pop up in bunches.  I was reading a
posting in an IBM news group where on programmer was trying to push
both NT and OS/2 by spawning threads.  I forget what he said NT crapped
out at - it was somewhat lower than a single OS/2 session could
generate, and he made a point that he could only launch 1500 threads
from a single process, although he could launch another process and
then add another 1500 until he hit the wall just short of 4095 (you're
right) system wide.  I haven't looked this up yet and I was not aware
of a per-process limit other than the system limit.

As for defaults, I see nothing wrong with 64 - that's enough to run a
bare bones command line session.  Warp 4 sets 1024, Warp 3 set (I
think) 256 with Warp connect setting 512.  Warp Server sets 4095, so
the default of 64 is already taken into consideration by the OS install

Will Honea <whonea@codenet.net>
========<end>=========================================


Bye,
    Vitus

--- Sqed/rexx 108:
 * Origin: OPERATOR! Trace this call and tell me where I am. (2:2474/424.1)

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

From: Thomas Seeling                                    14-Sep-99 09:32:29
  To: Eddy Thilleman                                    15-Sep-99 14:23:21
Subj: os/2 in teller machines

Hallo Eddy,

Am 11 Sep 99 um 22:09 schrieb Eddy Thilleman an Thomas Seeling:

 TS>> Most teller machines are using OS/2 to handle your money requests :).

 ET> I use OS/2 to view Wurste on my screen. ;-)

the plural is with a umlaut-u, in 7bit ascii (or crossword puzzles) you are
usually writing ue for umlaut-u, ae for umlaut-a etc. So it would be
"Wuerste".

I guess you are using jpeg or mpeg for viewing :)

Is anybody here using a video input device that comes with a documented API?


Tschau...Thomas

--- GEDW32 3.0.1
 * Origin: Die TeX-Box: +49-6036-980114 V.34/X.75 24h (2:2461/332.42)

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

From: Ian Moote                                         15-Sep-99 22:00:00
  To: VITUS JENSEN                                      16-Sep-99 07:00:23
Subj: Maximum threads.

VJ> If you don't mind any uneven distribution of CPU time see this post:

Thanks for all the additional info. So, although there is a system-wide 
limit of 4095, there is a per process limit of 1500? I think that's 
still workable for me. Hopefully I won't even approach 3000, but the 
potential's more than there to do so.

Take care and TTYL.

---
  This tagline is offensive.                        

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

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

From: Sean Dennis                                       16-Sep-99 16:04:11
  To: David Van Hoose                                   17-Sep-99 12:09:04
Subj: ... Perl

Hello David.

13 Sep 99 12:57, you wrote to me:


 SD>> Heheh-that's bad... ;)

 DH> Looks to me like a drunk trying to program blindfolded. :)
 DH> What does the rot(13) do?

ROT13 is a simple 'encryption' code (think of the 'Simple Caesar') that people 
use in USENET to prevent joke punchlines and tv show plot spoilers from being
read until you're ready.  GoldEd also supports this, but it's not encouraged
to use this in FidoNet.

It's extremely easy to write a program that does the same thing.

Later,
Sean

... "Words are very unnecessary/The can only do harm" -- Depeche Mode
--- AfterHours/2 and GoldED/2 : Enjoying the silence.
 * Origin: a..f..t..e..r..h..o..u..r..s..2..b..b..s (1:395/610)

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

From: Eddy Thilleman                                    17-Sep-99 00:14:21
  To: Thomas Seeling                                    17-Sep-99 21:57:14
Subj: os/2 in teller machines

Hello Thomas,

14 Sep 99 09:32, Thomas Seeling wrote to Eddy Thilleman:

TS> the plural is with a umlaut-u, in 7bit ascii (or crossword puzzles)
TS> you are usually writing ue for umlaut-u, ae for umlaut-a etc. So it
TS> would be "Wuerste".

German is not my strongest! ;-))

TS> I guess you are using jpeg or mpeg for viewing :)

No, PMView! :)

TS> Is anybody here using a video input device that comes with a
TS> documented API?

I know I don't...

  Greetings   -=Eddy=-        email: eddy.thilleman@net.hcc.nl

... "There's no place like home." "We can only hope."
--- GoldED/2 3.0.1
 * Origin: Windows98 is a graphic DOS extender (2:500/143.7)
102

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

From: MIKE RUSKAI                                       16-Sep-99 12:39:00
  To: IAN MOOTE                                         17-Sep-99 21:57:15
Subj: Maximum threads.

Some senseless babbling from Ian Moote to Vitus Jensen
on 09-15-99  22:00 about Maximum threads....

 VJ> If you don't mind any uneven distribution of CPU time see this post:

 IM> Thanks for all the additional info. So, although there is a
 IM> system-wide  limit of 4095, there is a per process limit of 1500? I
 IM> think that's  still workable for me. Hopefully I won't even approach
 IM> 3000, but the  potential's more than there to do so.

No, there's no set limit per process.  The only limitation is the 
per-process address space.  The larger the thread stack, the less threads 
you can start.  If you're going to use that many threads in a process, 
getting near the process address space limit (which, jumps to 3GB for 
32-bit programs running under Warp 5, AKA WSeB, and Warp Server 4), it's 
important to check all memory allocations, so you don't end up crashing 
your program.

Mike Ruskai
thannymeister@yahoo.com


... Almost everything in life is easier to get into than out of.

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

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

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