Hello everybody,

I've been asked to prep a formation for the fellow programmers on my team.
Most of them never programmed Windows and we're currently re-orienting
towards it. Anyways, one of the subject I'll be covering is the Win32 API
(obviously). I'm not going to get into the bloody details of it, but I'd
like to tell them (and know myself) what parts of Win32 are COM. I know
some/most of the shell stuff is COM, but what else?

I'm also wondering if ADO, DirectX and such "satellite" products are
considered part of the API (I'm guessing no..).

Thanks!

Alex.

On Wed, 10 Dec 2003 10:25:57 -0500, "Sin" <broa29@hotmail.com> wrote:

ADO, DirectX, etc... ;-)

Many useful controls.

Not to mention message queueing.



There's probably no clear definition of the API. Some things are clearly
part of the basic API (kernel32.dll, user32.dll, gdi32.dll). Some things
are not so clearly part. Generally I'd answer that anything you find
documented in MSDN Library is part of the Windows API unless it's only part
of a non-bundled product. E.g., the various Office programs are not part,
as I see it. But others may answer differently, and I don't think it's a
real useful distinction -- what would you use that distinction for?

What controls?
Message queuing? I take it you're not talking about Windows messaging...?

I just don't want to be informed on the subject more than anything...


Indeed. I'm guessing ADO and DirectX are not Win32 API, just complementary
products by their own. I see them as above Win32...


I like to have the global picture in mind so I can paint it to the newbies.
Remember I'm starting from scratch with most of these guys. They are all
windows _users_, but some of them don't even understand what a DLL is
exactly. I want to draw clear lines to separate the OS, the core API (gdi,
kernel, user, etc), the API extensions (ADO, DirectX, etc), services,
drivers, applications, etc. There's no other reason than putting them in
context and helping them better understand the beast.

If I were to explain to someoen what a car is, I'd tell them there's the
frame, the engine, transmission, body, wheels, etc... I'm trying to do the
same with Windows...

I think explaining all this to a newbie can also take down some of the
prejudice there might be towards Windows. Most of these programmers see
Windows as a lesser OS which is not well architectured, etc... I think the
Win32 API and other core components are a good place to start undoing this
wrong idea.

Alex.

On Wed, 10 Dec 2003 11:29:15 -0500, "Sin" <broa29@hotmail.com> wrote:

Argh. I don't like specific questions like that. ;-) But OK, one such
control -- the only one I remember for sure -- is the RichEdit common
control. You create it as an ordinary control, using CreateWindow/Ex.
You can then send it the message EM_GETOLEINTERFACE to get a pointer to
the control's IRichEditOle COM interface. And go on from there.

Hey, wait!

All the HTML controls!



That depends on what you mean by "Windows messaging".

I'm talking about the Windows COM+ support.

It's a support framework for distributed applications, integrated in Windows,
superceding Microsoft's earlier separate MTS (Microsoft Transaction Server)
solution.

It also integrates well with .NET.

Ah, there's a big question: is .NET part of the API or not?



Nhuh?


Whatever. They're part of standard Windows. You don't have to buy or
install anything extra.

"Sin" <broa29@hotmail.com> wrote in message
news:aRHBb.2316$aF2.290557@news20.bellglobal.com.. .
Rich edit is one: clearly this must use COM partly as rich edit controls can
embed OLE objects. Recall that rich edit controls use Windows messages for
most things.

Use of COM in the core APIs is pretty rare, and if you come across it
there's usually another way to do the same that doesn't use COM, if you
don't want to. For instance, the TAPI 1 and 2 APIs use a C interface,
whereas TAPI 3 uses COM. You could do most things you needed to using the C
TAPI 1/2 APIs.


Well, 'Windows messaging' could mean a couple of things -- Exchange/Outlook,
which could use COM, and SendMessage etc., which definitely don't. Message
queueing generally means MSMQ, which I guess isn't too relevant to the
typical Windows developer.

--
Tim Robinson (MVP, Windows SDK)
http://www.themobius.co.uk/

Haha! Who does?


Alright, I never used any of those... Well I did use the RicheEdit in VB,
but I guess that doesn't count


OK I though you were actually implying that COM had something to do in the
SendMessage/GetMessage/Etc. group... It didn't make sense, so I asked I
never used COM+, or even know what it is.


Ummm ok... Not very clear... I guess it'll be safer for me to skip COM+ in
my formation


I guess .NET is an API... But when refering to the Win32 API, I mean the
platform SDK. I don't think .NET falls into that category. I would consider
it more like something on top of Win32, but then again it extends Win32
alot, so it's more than just a wrapper. It's a fair guess to think there
won't be many new Win32 API functions in the future... Most new stuff will
be stuck right into .NET, a bit like the COM extensions....


Yep, I'm not trying to start a debate... I'm just trying to get the big
picture clear for myself before I try to explain it to others

Thanks alot, your comments are very appreciated!

Alex.

Hi Alex:

No flame wars please, just curious.

What, in your experience, has convinced you this is a
wrong idea?

What is the motivation for converting a Unix shop to
a Windows shop?

Thanks
Larry

Eummm... If you're asking then I take it you think that Windows IS a lesser
OS that is not well architectured. If so, then perhaps I should be asking
the question : What, in your experience, has convinced you this is NOT a
wrong idea?

Windows is one of the only tools in my toolbox which has never failed me. In
other words all the projects I've done on Windows went well, from start to
finish, and the OS itself or any aspect of it has never been a problem.

Can the same be said of Unix or other OSes? I'm willing to bet that yes. All
I know is that Windows is, to my standards, a very good OS. Perfect? Of
course not. That said I don't like the company that is Microsoft that much,
I really think they are killing off the competition, hence creativity and
evolution. I also think many aspects of Windows are problematic (security is
a joke). Does it make it a bad OS? I don't think so...


Well it's not a conversion per-say. The context is that we have several
plants which in the past needed a realtime OS to do their job. The OS we
were (and still are) using is QNX. It's not a Unix clone or variant, it's a
whole OS on it's own, but it does have many similarities (the command shell
is pretty much a clone).

Anyways, back then we would do all on QNX... Control applications, user
interface, etc. But now QNX is pretty much dead, it's been replaced by a new
OS which would require us ALOT of work to move to. We're currently on a
trend in which we are moving all user interface to Windows, as well as
control applications which CAN run on Window (most do, now that machines are
10x faster than they were... The Windows overhead is getting smaller and
smaller).

The goal is to lessen our dependency on QNX as much as possible... That way
the day we want to replace QNX we'll have much less code to port to whatever
other realtime OS we will choose. Another detail you might want to know
about is that QNX doesn't support alot of hardware, and that hardware is
getting rarer and rarer to find. It's just a question of time before we
can't use it at all unless we buy a shitload of old PCs... But this would
mean we'd be stuck on performance which is not an option either.

In other words we're going Windows cause we don't have much choice. I
personally like the move, cause I'm the Windows programmer of the bunch

Alex.

Sin wrote:


I asked you first. : )

Ok, I'm writing only my second Windows app. A
GUI interface of a difficulty level probably worthy
of a term assignment for a first or second term
Windows programming class.

My first application was an interface to a modem,
using MSDN's MTTTY as a pattern. I build industrial
control apps that run on Solaris PCs. So I have
experience with this type of application,
interfacing 50 or 100 devices.

Multithreading is a complexity added to any app
only when the situation requires it. I've never
needed to write a multithreaded application before,
though I have been thinking about doing a multithread
network server for my own education.

I remember posting to this group early in the
process that this modem interface would only need a
single thread. I envisioned code that would process
an event, like a mouse click, incoming data from the
modem, available buffer space for outgoing data to
the modem, then back to sleep. I'm sure you see the
flaw in Windows that makes that unworkable. The
serial data arrives on a different message queue!
One thread can't wait at two places, so multiple
threads, and their synchronization, are required.
Look, this isn't a killer, but it requires the
complication of multi threading for any serial
control application and is an example of poor
architecture, in my opinion.

In Unix, the process assigns a read callback
function for each file descriptor. The file
descriptors are for keyboards, serial ports,
sockets, pipes and similar interfaces, which
can look like files. These are written by the
developer and fire off when data arrives. The
developer also writes write callbacks, these
fire when there is room in the devices output
queue for data, so they are only enabled when
there is data to be written. It's all so simple.

I've just taken a look at MTTTY's document.
"The second part of an overlapped operation is
to detect its completion. Detecting completion
of the operation involves waiting for the event
handle, checking the overlapped result, and then
handling the data."

You see? A callback that calls the standard
C read() function and does something if the
message is complete or a process that plays the
complicated dance the MTTTY document describes?
That looks like another example of poor
architecture to me.

The callbacks I've described are an X Window
facility, but I liked it well enough to abstract
it for the somewhat less convenient select()
function for use in my non-X window work. The
abstraction is easy, and the raw select function
is also much simpler than Windows overlapped I/O.
In my opinion.

I'm an admitted Unix Bigot, but let's be honest.
While it has a reputation for being more secure
than Windows, Unix isn't exactly a bank vault either.

I'm doing these Windows applications to learn
about this operating system. I like working with
user interfaces, and I need to write for this market.
It's been educational.

I'd encourage any Windows or Unix developer to do
as I have and give the other platform a fair test.

For one thing, you meet the nicest people in the
newsgroups.

Alex, I appreciate your response, and never
intended for this to be a flame, or a troll.

Larry

Ah, that explains the sckeptism


Oh so you're in a situation similar to that of the programmers I work with.
We don't deal with systems that big though...


Ummm I have no experience with serial communication in Windows but I'm sure
there are other ways. There are numerous ways for a thread to wait on two or
more events. See below...


Again I haven't worked with overlapped IO. If "waiting for the event handle"
is using WaitForSingleObject(), then check out the doc on
WaitForMultipleObjects() as well as MsgWaitForMultipleObjects().

One of the nice things about waiting for events in Windows is that there are
often severals ways to do it.


Just so you know, the standard select() function is also available in
Windows. Overlapped IO, if I'm not mistaken, is used when scalability is
required... If the modem stuff works like or with Winsock, then Overlapped
IO is an option, not an obligation.


Of course. It's also a much smaller target form a global point of view. The
efforts put towards the destruction of Windows are far superior than any
other OS. A couple years ago I figured they woud eventually wear out the
bugs but man, it's getting ridiculous. It's like they add two new bugs each
time they fix one...


I don't have that much experience with Unix or it's clones, but I do know
enough to have an educated opinion about it. While it's certainly more solid
and clear, it doesn't, IMHO, offer as much as Windows does. Not that Windows
is better, but there's definitly more effort being put into it than any
other OS out there, both in manpower and $$$.

If you can't fight it, join it It sure looks like the Linux trend is
dying off... So it looks like Windows ain't a choice, but a reality for
programmers unless you like to live on the edge


Damn right!


No problem Larry, I didn't see it as such.

Alex.

Sin wrote:

I think you are mixing up your API's. IMHO none of the Win32 API
is COM based. To me the Win32 API is a collection of Pascal calling
convention, "C like" functions that provide low level access to the
windows operating system.

This is true. The shell is a COM layer built on top of the Win32
API. At this higher level Windows is nearly all COM and the COM
layer gives you access to the desktop.

Again, these all are different to Win32. The DirectX is a API that
allows access to the operating system screen buffer, ADO is and API
layer used for database access and both are not part of the WIN32
API.

Microsft has many published API's, MAPI, TAPI, WinNet etc etc
all of which are not part of the Win32 API.

Jussi Jumppanen
Author of: Zeus for Windows, Win32 (Brief, WordStar, Emacs) Text Editor
"The C/C++, Java, Pacal, Cobol, Fortran programmers text editor"
Home Page: http://www.zeusedit.com

In article <3FD91ABB.7050805@nospam.com> larryl@nospam.com
(Larry Lindstrom) writes:

You can do it without multi-threading. I have written a data
collection application that monitors several serial ports and
buffers incoming data to disk. Other programs can send requests
to this program, which can return buffered data or pass data
from the calling programs out the serial ports. Basically it's
a buffered serial port server - and of course it also handles
user events. I avoided multi-threading so that it would be easier
to port the program to Unix (where I use select() to handle things).
This program has been running 24/7 in a couple of thousand customer
sites for several years.

Different strokes... Under Windows, other programs call mine by
sending request packets with WM_COPYDATA messages, and my program
returns results the same way. The Unix version uses pipes. Every
now and then I get the urge to change everything over to sockets,
but "if it ain't broke, don't fix it" - although I have added
socket options to satisfy some of our networked customer sites.

I chose to avoid overlapped I/O - like multi-threading, it looked
like a complication that I could do without (and again, it would
hamper Unix portability). Non-blocking reads, combined with
appropriate message handling, works fine for me; a 500-ms timer
lets me block on the message queue and avoid chewing up CPU time
while providing immediate response to program requests and user
events with acceptable latency on serial port input.

--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!

Sin wrote:
Hahaha, yea, that must be it.

< Snip >

Serial communications? Different devices
are opened differently, for example server
sockets and client sockets require different
code to be opened. Read pipes and write pipes
have to be opened in the correct order. But
these simple operations return integer file
descriptors. And the callback that services a
pipe will service a socket or a serial
port that uses the same protocol. Won't MTTTY's
serial com code service a socket or a pipe,
after the device has been properly opened?
It's been a long time since I looked at the
code.

< Snip >

Well, I'm always coding for performance. And
I hope all the trouble I went through with MTTTY
would serve as the foundation for something more
ambitious. If MSDN is offering MTTTY as an example
I'd be disappointed if I found it was an example of
crappy code. But MSDN often disappoints me.

< Snip >

A less solid and clear operating system sounds like
"a lesser OS which is not well architectured".

Is this a server application? Are there Unix skills
among your co-workers? Is there interest among your
co-workers in a Unix solution?

I don't know enough to suggest an operating system,
but I urge you to have an open mind when deciding on a
platform. You expressed an important goal, to "take
down some of the prejudice".

I'm learning a lot in my struggle with Windows. Feel
free to chime in on my "DialogProc Wont Trap My WM_CHAR,"
thread if you have any suggestions. A Unix application
is an experience you might find valuable.

I don't care for Linux. But I see no evidence of it
dying off. If you decide to try Unix, I'd recommend
Solaris.

Again, thanks for this discussion.

Larry

Charlie Gibbs wrote:

Nice reliability. The only time one of my
production installations broke, requiring my client
to send workers home and me to fly half way across
the U.S. my first question after opening the case
was "Why isn't the CPU fan turning?".

How do you find working with the two operating
systems?

I've been told I don't have to multi-thread, but
I've gotten the impression it is the most straight
forward method for a high performance solution.

Where can I read about single threaded event
processing for communication applications?

As I asked Alex, what's the difference between
socket code and pipe code? Other than opening the
devices.

Yea, I'd like to know more of that technique.
Would it lend itself to a high performance
solution for the number of devices I'm trying to
control?

You might be interested in the following
project. I haven't used this, but I believe it
puts most of the Unix API on Windows. This might
be the solution to your porting problems.

http://cygwin.com/

Thanks
Larry

In article <3FDAC490.8000303@nospam.com> larryl@nospam.com
(Larry Lindstrom) writes:

Thanks.

Don't you just love users like that? At least some of them
are decent enough to apologize for blaming your stuff for
the failure.

Actually, it's more like five. Our software started out under
MS-DOS, and I continue to support that version for the die-hards
out there. Our first Windows port was in 1994, hence was for 3.1;
I added 32-bit equivalent code where necessary when doing the Win95
conversion. Currently I'm generating code for MS-DOS, Windows 3.1,
32-bit Windows, SCO Unix, and Linux from the same code base.
Needless to say, the C preprocessor gets quite a workout, although
I've developed some conventions that ease a lot of the pain. And
having six compilers look at the code with all warnings turned on
(just for the hell of it I run the Win32 version through an old copy
of MSVC as well as my regular Borland compiler) is at least as good
as lint. The MS-DOS/Win3.1/Win32 makefile is a monster. :-)

I use standard C run-time library functions wherever possible, e.g.
fopen() instead of CreateFile(), time() instead of GetSystemTime(),
etc. If a function has no C RTL equivalent (e.g. GetOpenFileName()
or MessageBox()), I write library routines that under Windows are
just wrappers around the Windows API; for other OSes these functions
implement the equivalent functionality the hard way. The important
thing is that the calling conventions remain the same regardless of OS.

A more radical example is where most people would use a dialog box.
I call a routine that opens a window and sets up child controls.
The calling program passes this routine a pointer to a table that
describes the fields I want to display and/or receive data from.
This routine already existed as a curses-based routine in the MS-DOS
and Unix versions; it was much easier to just port it to Windows
than to overhaul every program that called it.

Still, handling a GUI is nothing like using curses, so there are
fair-sized blocks of code that are either Windows-only or non-Windows.
I can often factor out much of the guts into functions that are
common to both, but the fact remains that we're dealing with two
very different beasts here.

One of my main "cheats" is to put my GetMessage() call in the
middle of a console-style mainline routine, rather than using
the classical technique of a little message loop at the end of
WinMain(); when GetMessage() unblocks it falls through my main code,
which checks for what just happened. I use it much like the Unix
select(), and indeed the corresponding Unix code is often simply a
call to select(). Typically, under Unix I have to call various APIs
to get status information, while under Windows I can usually just look
for things that I've already set in my window procedure. I'll pump
any remaining messages through the queue by calling this little routine:

void winpump (void)
{
MSG msg;

while (PeekMessage (&msg, NULL, 0, 0, PM_REMOVE)) {
TranslateMessage (&msg);
DispatchMessage (&msg);
}
}

This routine doesn't block, so I can call it whenever I want
to make sure that messages keep flowing. This way I can enjoy
the benefits of event-driven code while preserving a conventional
program flow that is more easily portable to other OSes.

One of the things that makes the job easier is that I don't try to
go anywhere near the bleeding edge. The fact that I'm working in a
production environment, as opposed to (for instance) writing games,
means that I can get by with writing much plainer-looking applications.
Some customers might grumble at first about the lack of flashy bells
and whistles - but they'd get even more upset if a revenue-generating
application goes down, so they usually get over it. And in time, most
of them come to realize that the lack of gratuitous flash actually
makes the software easier to use - especially if they're the ones
actually using it day in and day out. We've had a lot more compliments
about how easy our software is to use than we've had complaints about
the fact that it's not another video game. When the rubber meets the
road, rampant featuritis only gets in the way.

Dunno - I just made this stuff up on the fly. I read a lot of API
references and did a lot of experiments to figure it out. But to
get you started, here's how I set up a serial port:

serfd = CreateFile (portname, GENERIC_READ | GENERIC_WRITE,
0, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (serfd == INVALID_HANDLE_VALUE) {

/* Can't open the serial port! */

}
SetupComm (serfd, inbufsize, outbufsize);
PurgeComm (serfd,
PURGE_TXABORT | PURGE_TXCLEAR | PURGE_RXABORT | PURGE_RXCLEAR);
memset ((void *) &commtimeouts, 0, sizeof (commtimeouts));
commtimeouts.ReadIntervalTimeout = MAXDWORD; /* Don't wait */
commtimeouts.ReadTotalTimeoutMultiplier = 0; /* for data - */
commtimeouts.ReadTotalTimeoutConstant = 0; /* take what's there. */
commtimeouts.WriteTotalTimeoutMultiplier = 20000L / baudrate;
commtimeouts.WriteTotalTimeoutConstant = 0; /* Time-out for writes */
SetCommTimeouts (serfd, &commtimeouts);

This SetCommTimeouts() call sets up the port for non-blocking reads.
(You can find the detailed explanation in your API reference under
COMMTIMEOUTS.)

Probably not a lot, now that you mention it. But the systems
I wrote the original Unix code for weren't networked; neither
was my development box, which at the time didn't even have the
socket libraries. For that matter, neither did my brain; I
didn't learn socket programming until much later.

See above.

I keep telling myself I should check it out, for the command-line
utilities if nothing else. I really miss having decent grep and
diff programs...

--
/~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!