To output "Hello, World!" at window

[luser- -droog]

Using the old GDI API directly *is* difficult.

Example 1: try drawing a graphic element in a certain colour. You can't just
select an RGB colour as you might expect; you have to create and allocatea
special 'pen' object, apply a colour to it, attach it to a device context,
use it, then deattach it, and deallocate it when you don't need that colour
anymore! (Or something along those lines.)

Example 2: once you've managed to draw your graphics, and then the windowis
obscured then uncovered, or minimised/restored, then your graphics will have
disappeared and have to be recreated! The original source data (random
numbers, arbitrary input from a stream, etc) no longer exists.

Your application has to written around always being able to *quickly*
recreate whatever is in any window. Which is a complete pain.

And that's true of pretty much everything in GDI. (And trying to use GDI+
from C is a magnitude or so worse, because it assumes C++)

It's not uncommon for a window system to require the client to redraw
the window. Even in X11, XSetWindowAttributes wa.backing_store is
still
just a hint.

 

[Malcolm McLean]

Example 1: try drawing a graphic element in a certain colour. You can't just
select an RGB colour as you might expect; you have to create and allocatea
special 'pen' object, apply a colour to it, attach it to a device context,
use it, then deattach it, and deallocate it when you don't need that colour
anymore! (Or something along those lines.)

Example 2: once you've managed to draw your graphics, and then the windowis
obscured then uncovered, or minimised/restored, then your graphics will have
disappeared and have to be recreated! The original source data (random
numbers, arbitrary input from a stream, etc) no longer exists.

Your application has to written around always being able to *quickly*
recreate whatever is in any window. Which is a complete pain.

And that's true of pretty much everything in GDI. (And trying to use GDI+
from C is a magnitude or so worse, because it assumes C++)

At risk of being topic-flamed, you don't do it like that.

To get round problem 2, you create a window of the class you want. Say
for the sake of argument we want to have a window that shows a traffic
light.

We hang off the window all the data that represents the light - for a
simple light, it might just be an integer representing red, green or
amber, or it might be considerably more complicated with cycles and
various shapes and intensities and so on.
Now we intercept the WM_PAINT message, and we regenerate our traffic
light on demand.

To get round problem 1, you create a "raster" object. This consists of
a 24-bit pixel-addressable array. It keeps backing store. In the olden
days, when Windows was new, this was too heavy on computer memory.
However nowadays it's not a problem.
You simply write all the graphics on top of the raster. That's how do
do anything more than trivial graphics. (If you need really
complicated graphics, you go to Open GL or something similar, to avoid
endlessly rewriting anti-aliasing and 3d transform code).

 

[Chris H]

I just took a brief look at comp.os.ms-windows.programmer.win32,
and it seems to have roughly as much activity as comp.lang.c.

There seems to be a lot more spam these days and far fewer real
messages. That is an observation from most of the NG's I see. Usenet
seems to be slowly dying

 

[Keith Thompson]

In message <[email protected]>, Keith Thompson <kst-
(e-mail address removed)> writes [...]

I just took a brief look at comp.os.ms-windows.programmer.win32,
and it seems to have roughly as much activity as comp.lang.c.

There seems to be a lot more spam these days and far fewer real
messages. That is an observation from most of the NG's I see. Usenet
seems to be slowly dying

I don't see much Usenet spam these days; eternal-september.org seems to
do a pretty good job of filtering it out. (When I view comp.lang.c in
Google Groups, I hardly recognize it.)

 

[Chris H]

In message <[email protected]>, Keith Thompson <kst-
(e-mail address removed)> writes [...]

I just took a brief look at comp.os.ms-windows.programmer.win32,
and it seems to have roughly as much activity as comp.lang.c.

There seems to be a lot more spam these days and far fewer real
messages. That is an observation from most of the NG's I see. Usenet
seems to be slowly dying

I don't see much Usenet spam these days; eternal-september.org seems to
do a pretty good job of filtering it out. (When I view comp.lang.c in
Google Groups, I hardly recognize it.)

Thanks that looks useful. I not it only carries text groups.... I have
advocated that for a LONG time.

One reason is that now "everyone" has their own on line web space binary
groups are no longer needed in the same way they once were.

The second reason is a hell of a lot of the stuff in binary groups
breaches copyright. Most if not all the film, cd and dvd groups. Not to
mention the porn. I have no problem with porn but I suspect most of the
stuff posted is not posted by the copy right owners.

However looking at the amount of technical (if not on topic posts
seems to be declining over the last few years.

 

[Michael Press]

He has an interesting argument though.
He says I am delusional.
I am also on the ISO C committee.
So where does that leave his argument?

ISO C is more and more an irrelevant bureaucracy
accumulating featherbedders, goldbricks, hangers on,
and camp followers; interested in justifying its own
existence, and, as a weather vane, turning which ever
direction the corporate wind blows rather than anything
else? Where do you think it leaves his argument?

 

[Michael Press]

Oh, you really don't want to go down that path ...

Whoops! I already did.

 

[Chris H]

ISO C is more and more an irrelevant bureaucracy
accumulating featherbedders, goldbricks, hangers on,
and camp followers; interested in justifying its own
existence,

That has been true.... there are some, certainly on the national
bodies, who are not programmers but do it as a hobby.

and, as a weather vane, turning which ever
direction the corporate wind blows rather than anything
else?

This is not the case and provably so. Had it been the case C99 would
have been what the corporate players wanted and therefore implemented
even before the ink was dry. As it was with C90.

Where do you think it leaves his argument?

Confused.

 

[Matt Ryder]

On 2011-04-13 16:56:32 +0100, Wonyong said:



Ouch.
One point I would add to this, is the use of system();

In it's place, if you really want to do it with an OS indepenent
approach, I advise scanf() instead.

Matt.