David H. Burns wrote:
> I assume you mean "F*** you David".

In the context quoted I think FUD is supposed to be the more common acronym 
"Fear Uncertainty Doubt" and not related to your name.

	Thorsten, POV-Team

PS: Note that your post was off-topic to this group.

Post a reply to this message

Thanks, I'd like to think so but I'd never seen the acronym and have no idea
what "Fear Uncertainty Doubt" might mean.
> In the context quoted I think FUD is supposed to be the more common 
> acronym "Fear Uncertainty Doubt" and not related to your name.
> 
>     Thorsten, POV-Team
> 
Yes, and I apologize. I was expressing my frustration and not saying 
anything
useful.
> PS: Note that your post was off-topic to this group.

Post a reply to this message

David H. Burns wrote:
> Thanks, I'd like to think so but I'd never seen the acronym and have no 
> idea what "Fear Uncertainty Doubt" might mean.

Google ;-)

	Thorsten

Post a reply to this message

Thanks, Thorsten. So tcgetattr's comment, when understood, was more or
less appropriate. I remember an old BC cartoon which pictured the dinosaurs
speaking in acronyms before their extinction.

David

Thorsten Froehlich wrote:
> David H. Burns wrote:
>> Thanks, I'd like to think so but I'd never seen the acronym and have 
>> no idea what "Fear Uncertainty Doubt" might mean.
> 
> Google ;-)
> 
>     Thorsten

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> David H. Burns <dhb### [at] cherokeetelnet> wrote:
> > This question may be ignorant or off-topic but: How does Pov-Ray
> >   "plot" images in Windows.
>
>   You should read the Windows API documentation. There are also tons of
> wrappers around that API which make it easier.

I recall that when I first tried to do pixel graphics output on a Windows
machine and tried to make any sense of the API, I thought something like "WTF -
I can't possibly need *all* this crap just to paint a single pixel?!"

I mean, come on - the underlying concept has some brain-dead aspect to it for a
multitasking windowing GUI OS: An app needs to re-draw its contents whenever
some other window has been drawn atop and is now moved away again? Can't some
abstraction layer just buffer the whole smash and blit it all over again when
the other window has been moved aside again?

Granted, at the time the API was designed, any other mode of operation would
have appeared to be a waste of memory: Even 2D accelerator cards were still
cutting-edge technology, found only in professional workstations, and it's easy
to criticize with 20/20 hindsight. But anyway: I can perfectly understand why
someone would rather have some sample code to try to adapt, than try to dig
through the API docs themselves. After all, they do *not* make very good
tutorials.

Post a reply to this message

David H. Burns wrote:

> to be intended for VC++. I suppose that's OK, PovRay is written in VC++.
> Since Microsoft controls virtually all of the computer industry and most
> computer hardware is built for Microsoft software

I think your confusing matters a bit. PovRay is available
for multiple platforms including Linux, so the code certainly
is not Microsoft-centric. The Windows version does require
to use the Windows API for platform specific functionality
though. This is not very surprising and not specific to the
compiler used. At the very bottom of it, it's the operating
system which will paint a bitmap on the screen. The graphics
classes of C++ Builder internally use that API as well.

Noone forces you to love Microsoft but I can't help wonder
why you're using Windows in the first place ;)

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I suppose that's OK, PovRay is written in VC++.

Actually it isn't. It nowadays does come with project files to conveniently
compile with MS Visual Studio, but it doesn't use the MFC framework, nor any
other framework provided by Microsoft, and may compile just as well with any
other C++ compiler suite. POV-Ray 3.6 official releases were actually built
using the Intel compiler suite; the source code releases didn't even provide
any particular support for Visual Studio back then, so any VS user had to set
up their own project files to compile POV-Ray.

> Since Microsoft controls virtually all of the computer industry and most
> computer hardware is built for Microsoft software, there seems little point
>   in going to a lot of trouble trying to learn something else or to
> adapt code
> written in any but Microsoft languages to work on computers using
> Windows.

That, too, is a common misconception - though not surprisingly. Yes, most
*desktop computer* hardware is designed to run Windows. They *dominate* the
market to a good degree, but to say that they *control* it would be
exaggerated. Mac is too strong in the desktop segment, and Unix derivatives are
too strong in both the desktop and server segments, to let Microsoft just have
their will. Not to mention all those mobile phones, PDAs and embedded systems
which I'd consider part of the computer industry, too: Microsoft has achieved
and maintained a foothold in that segment with Windows CE and especially .NET,
most particularly with smartphones, but I guess in the mobile phone segment
Symbian OS is still strongest, with new competitors gaining ground, and
embedded systems tend to run the wildest operating systems you can possibly
imagine.

And then there's customer power that don't let MS just have their will. Yeah,
sure, the private end users seem to swallow all MS has OEMs cram down their
throat bundled with new PCs. But for instance Vista was an absolute no-go in
most professional environments, which was a serious blow to MS. Serious enough
to release the first Service Pack for Vista under an all-new name... no, not a
name - a good old version number. Imagine that. How come? End user pressure?
Bloody likely not. But companies don't go for those fancy names, and it seems
like Microsoft needed to make a statement that they're heading back for more
serious business.

If Microsoft lost their commercial desktop market share to, say, Mac OS or
Linux, I guess they'd lose their private user market share very soon thereafter.
It's quite convenient to use the same OS at home that you need to familiarize
yourself with at work anyway.

So no, they're not controlling the market. I'd rather say it's the market that
controls them.

Post a reply to this message

My point exactly. Playing with working code is often the best tutorial. 
But, alas,
much available code was written before XP and apparently the API functions
have changed. But then I read that Microsoft Visual Whatever version 8.0 is
incompatible with Version 7.0 .... One seems trapped.

David


clipka wrote:

 > But anyway: I can perfectly understand why
> someone would rather have some sample code to try to adapt, than try to dig
> through the API docs themselves. After all, they do *not* make very good
> tutorials.
> 
> 
>

Post a reply to this message

> Noone forces you to love Microsoft but I can't help wonder
> why you're using Windows in the first place ;)

Stupidity, sheer stupidity! Though economics and the reluctance to abandon
what I'm used to enters into it. I almost bought a Mac instead of the PC I
bought recently. I've kicked myself ever since.

But many are forced to use Windows. At work, one has to use what
one's employer will provide.

But I have learned some things lately. If one wants to do any 
programming for
Windows, one must learn the Windows API. To many things, such as
memory management, are involved. I had a vastly overly simplistic view
  of the situation. I wonder how Linux does things, but I'm afraid 
learning it
at this point is not a live option.

David

Post a reply to this message

clipka wrote:

> That, too, is a common misconception - though not surprisingly. Yes, most
> *desktop computer* hardware is designed to run Windows. They *dominate* the
> market to a good degree, but to say that they *control* it would be
> exaggerated. 

Yes, "dominate" is definitely the word I should have used. And I 
probably should
have said "PC computer market".

David

Post a reply to this message