Process and Threads with Windows XP/NT

I've written an application under linux which creates one thread and
they communicate in one direction. I've used POSIX-Threads. Now I want
to port this app to Windows. Are there any online-docs for
Windows-Threads? Where?

Perhaps it could be easier to port my app from using threads to
processes. Does someone know a good online-documentation for Windows
processes and their communication with each other?

And please, say not cygwin. It must be windows native. ;-)

Thanks
Andreas

Ups. I found it the solution at IBM Developerworks.

But perhaps someone could give me a hint for windows process
communication. Sorry for this little bit OFF-Topic.

Andreas

Define "windows native", please.

regards,
alexander.

--
You Could Have Won >>ONE MILLION<< At http://sources.redhat.com/pthreads-win32

You May Also Want To BUY Microsoft Windows >>UNIX<< for $50-$99 (plus $30/CAL)

http://www.infoworld.com/articles/pl/xml/02/07/29/020729plmsu.xml
(REVIEWS: A nod toward Unix... PROS: + Bypasses Win32 API for performance
+ Superior performance to Win32 API
+ Price is unbeatable)

ftp://ftp.microsoft.com/developr/Interix/sfu30/POSIX1Conformance.doc
(Microsoft Windows Services for UNIX 3.0 Interix POSIX.1 Conformance Document)

ftp://ftp.microsoft.com/developr/Interix/sfu30/POSIX2Conformance.doc
(Microsoft Windows Services for UNIX 3.0 Interix POSIX.2 Conformance Document)

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windows2000serv/deploy/sfu/sfuposix.asp
(Writing POSIX-Standard Code)

http://www.microsoft.com/windows/sfu/default.asp
(Services for UNIX Home)

http://www.microsoft.com/windows/sfu/productinfo/trial/default.asp
(Trial Software Windows Services for UNIX 3.0)

http://www.microsoft.com/windows/sfu/support/xnews/default.asp
(microsoft.public.servicesforunix.general)

#include <disclaim.er>

"Under Microsoft's Copyright," no doubt. :-)

Duke

And how much do you want for a link?

regards,
alexander.

Nothing ;-)

Here is it:
http://www-106.ibm.com/developerworks/linux/library/l-rt7/?Open&t=grl,l=252,p=mgth

Another question. Where is the difference between "CreateThread" and
"_beginthread".

Andreas

No, I mean the ability to run on a fresh installed Windows without
modifications. (Perhaps this must be "Under Microsoft's Copyright".)

I could choose a portabel Windows and Linux thread library. But at first
I develop for Linux, Solaris, IRIX and all other unix-like systems. I
must choose a lib that works on all these systems.

Perhaps it works for all expect of IRIX (or another). Then I've no IRIX
compaitibility because off Windows compatibility. This price is too high
for me. I will better go the hard way. Programming with POSIX and do the
windows port.

Andreas

--
========================================
Max Khesin, software developer -
m...@cNvOiSsPiAoMntech.com
[check out our image compression software at www.cvisiontech.com, JBIG2-PDF
compression @
www.cvisiontech.com/cvistapdf.html]

"Alexander Terekhov" <tere...@web.de> wrote in message
news:3DD11DFE...@web.de...

"_beginthread" does some initialisation needed to use the standard C
library, and if you're planning to do so you shouldn't use
"CreateThread". "_beginthread" is generally deprecated in favour of
"_beginthreadex".

Yeah, there's a lot of amusing drek out there, on IBM developerworks too.

Forget it. Stick to pthreads-win32's pthread_create() (And, BTW, it
doesn't set errno; the exact error number/status is reported as non-
zero return value).

Well, as for processes/IPC vs threads/threading, I really like this:

A) http://groups.google.com/groups?selm=Jkta8.51%241h5.372%40news.cpqcorp.net
(Subject: Re: pthreads vs. IPC: what to use when?)

B) Isolation aside, "Program Management Model": < that's from OS/390
(and z/OS) Language Environment" docs, © Copyright IBM Corp. 1991,
1996 (1996, 2002) >

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/CEEA8130/3.1.1
("3.1.1 Language Environment Program Management Model Terminology")

"....
Some terms used to describe the program management model are common
programming terms; other terms are described differently in other
languages. It is important that you understand the meaning of the
terminology in a Language Environment context as compared to other
contexts. For more detailed definitions of these and other Language
Environment terms, consult the "Language Environment Glossary" in
topic GLOSSARY.

General Programming Terms:

Application program
A collection of one or more programs cooperating to achieve
particular objectives, such as inventory control or payroll.

Environment
In Language Environment, normally a reference to the run-time
environment of HLLs at the enclave level.

Language Environment Terms and Their HLL Equivalents:

Routine
In Language Environment, refers to either a procedure,
function, or subroutine.

Equivalent HLL terms: COBOL--program; C/C++--function;
PL/I--procedure, BEGIN block.

Enclave
The enclave defines the scope of HLL semantics. In Language
Environment, a collection of routines, one of which is named
as the main routine. The enclave contains at least one thread.

Equivalent HLL terms: COBOL--run unit, C/C++--program,
consisting of a main C function and its subfunctions,
PL/I--main procedure and its subroutines, and
Fortran--program and its subroutines.

Process
The highest level of the Language Environment program
management model. A process is a collection of resources,
both program code and data, and consists of at least one
enclave.

Thread
An execution construct that consists of synchronous
invocations and terminations of routines. The thread is
the basic run-time path within the Language Environment
program management model, and is dispatched by the system
with its own run-time stack, instruction counter, and
registers. Threads may exist concurrently with other
threads.

...."

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/CEEA8130/3.1.2
("3.1.2 Program Management", "Figure 3. Language Environment Resource Ownership)

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/CEEA2130/3.2.1.3.1
("3.2.1.3.1 The Enclave Defines the Scope of Language Semantics"

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/CEEA2130/5.4
("5.4 Chapter 31. Using nested enclaves)

"....
Language Environment explicitly supports the execution of a single enclave
within a Language Environment process. However, by using the system services
and language constructs described in this chapter, you can create an
additional, or nested, enclave and initiate its execution within the same
process.

The enclave that issues a call to system services or language constructs
to create a nested enclave is called the parent enclave. The nested enclave
that is created is called the child enclave. The child must be a main routine;
a link to a subroutine by commands and language constructs is not supported
under Language Environment.

If a process contains nested enclaves,

none or only one enclave can be running with POSIX(ON)."
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

http://publibz.boulder.ibm.com:80/cgi-bin/bookmgr_OS390/BOOKS/CEEA2130/5.4.2.4.1
("5.4.2.4.1 z/OS UNIX considerations")

"....
To create a nested enclave under z/OS UNIX, you must either:

Be running with POSIX(OFF) and issue system(), or

Be running with POSIX(ON) and have set the environment variables
to signal that you want to establish a nested enclave. You can use
the __POSIX_SYSTEM environment variable to cause a system() to
establish a nested enclave instead of performing a spawn().
__POSIX_SYSTEM can be set to NO, No, or no.
...."

regards,
alexander.

Ha, thanks!

regards,
alexander.

--
You Could Have Won >>[http://tinyurl.com/2nl1]<< at [http://tinyurl.com/2jdf](*)
(*) POSIX(R) Threads for Win32(R) Project hosted by [http://sources.redhat.com/]

#include <disclaim.er>

One hears this once in a while. It sounds, to me, utterly ridiculous.

Let's try out two plausible definitions of "windows native":

1) Uses only Win32 APIs.

Extreme interpretation:

OK, so your application defines no interfaces of its own? It's merely
a main() that calls Win32 APIs? No? So what's so different about using
a 3rd party API defined neither by you nor Windows?

Reasonable interpretation:

On the other hand, the "cygwin" DOES ultimately use Win32 APIs, and
thus is no different from calling your own routines.

2) Runs on an "out of the box" Windows system:

Extreme interpretation:

I suspect you'll find that your application will NEVER run "out of
the box". That is, your application probably is NOT bundled with the
Microsoft distribution of Windows. It must be installed on top of that
distribution. Thus, unless you work for Microsoft, you're out of luck
and the question of which thread interfaces to use becomes moot.

Reasonable interpretation:

You're going to install your application on top of the Windows system;
so what's so different about installing the additional APIs along with
it? "Win32 pthreads" is open source and imposes no licensing fees or
distribution restrictions (it's LGPL). So what's the problem?

--
/--------------------[ David.B...@hp.com ]--------------------\
| Hewlett-Packard Company Tru64 UNIX & VMS Thread Architect |
| My book: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\----[ http://homepage.mac.com/dbutenhof/Threads/Threads.html ]---/

http://msdn.microsoft.com/

Under MSDN Library, Windows Development, Windows Base Services, DLLs
Processes and Threads, SDK Documentation, DLLs Processes and Threads,
Processes and Threads, give or take a few nodes in the tree :-)

Why do you think so?

That would be MSDN. See above for a link (you'll probably want to look
at the MSDN Library link).

Ziv