So now I'm wondering if Windows provides any easy way to load and save 
bitmapped images. GDI appears to allow you to load and save in Windows 
Bitmap format - arguably amoung the worst file formats *ever*. But what 
about something more sane?

Well, DirectX doesn't seem to have anything useful. (Gotta love the way 
half the stuff on MSDN turns out only to be applicable to Windows 7. 
Yeah, like I really care about that...) I did eventually find something 
that appears to do exactly what I want. Not quite sure which versions of 
Windows support it, but it looks interesting.

Reading further, it seems you have to link this special file into your 
application. (That can't be good...) And then it starts talking about 
something called COM, and I got *completely* lost.

...so now I'm trying to figure out what the hell COM is. :-/

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> (Gotta love the way 
> half the stuff on MSDN turns out only to be applicable to Windows 7. 

That is the one problem with Microsoft's online documentation. They don't 
put the old stuff online in a way that's easy to find. If you don't stay on 
the upgrade treadmill, you need to buy copies of the documentation if you 
want to keep working.

> Reading further, it seems you have to link this special file into your 
> application. (That can't be good...) 

What kind of file? Probably a COM stub.

> And then it starts talking about 
> something called COM, and I got *completely* lost.
> 
> ...so now I'm trying to figure out what the hell COM is. :-/

Object-oriented remote procedure calls. You know what object-oriented is? 
You know what remote procedure calls are? Slap the two together. That's COM. 
It's typed and reflexive. It's basically one step up from DLL, in that it 
can be a DLL running in a separate process or even a separate machine (via 
"DCOM"). You're probably linking in a file that takes your local procedure 
calls, packages up (aka "marshalls") the arguments, and then sends them to 
the COM subsystem which delivers them to the appropriate task for execution.

It's basically how all software talks to other software on Windows if you 
don't want to be hard-coding stuff in at compile time like function offsets. 
It's how Word talks to Excel, how the help subsystem talks to IE, how 
ActiveX talks to IE, and how Windows Scripting Host talks to everything. 
Pretty much every line using an "object" in WSH is talking to that object 
via COM.


-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

>> (Gotta love the way half the stuff on MSDN turns out only to be 
>> applicable to Windows 7. 
> 
> That is the one problem with Microsoft's online documentation. They 
> don't put the old stuff online in a way that's easy to find. If you 
> don't stay on the upgrade treadmill, you need to buy copies of the 
> documentation if you want to keep working.

But of *course*, if you're writing new software, you will only be 
interested in making it work for Windows 7 (which, I add, isn't even 
available yet). Why would you want to target the OS that 99% of your 
market is still using when you could target some brand new unreleased 
one and thus force everybody to actually buy it?

>> ...so now I'm trying to figure out what the hell COM is. :-/
> 
> Object-oriented remote procedure calls. You know what object-oriented 
> is? You know what remote procedure calls are? Slap the two together. 
> That's COM. It's typed and reflexive. It's basically one step up from 
> DLL, in that it can be a DLL running in a separate process or even a 
> separate machine (via "DCOM"). You're probably linking in a file that 
> takes your local procedure calls, packages up (aka "marshalls") the 
> arguments, and then sends them to the COM subsystem which delivers them 
> to the appropriate task for execution.
> 
> It's basically how all software talks to other software on Windows if 
> you don't want to be hard-coding stuff in at compile time like function 
> offsets. It's how Word talks to Excel, how the help subsystem talks to 
> IE, how ActiveX talks to IE, and how Windows Scripting Host talks to 
> everything. Pretty much every line using an "object" in WSH is talking 
> to that object via COM.

After spending a couple of hours on this, here's what I managed to 
figure out:

- A DLL is a file containing a set of procedures. You can dynamically 
load it into memory and call these procedures. (I'm not precisely sure 
how...)

- RPC is both a network protocol and a system for calling procedures in 
another running program. This program may or may not be running on the 
same computer.

As best as I can tell, you write a list of procedures that you want to 
be able to call remotely, and run this through the MIDL compiler. This 
spits out two blobs of code. You link one into your client, and it 
enables you to call these procedures just like any other procedure. 
However, what the generated code actually does is scoop up the 
parameters passed, serialise them somehow, and then presumably call some 
secret undocumented Win32 function to actually send this data somewhere. 
The data is then sent either via local IPC or network RPC packets to the 
server side.

The code blob linked into the server then unserialises the data and 
calls the actual procedure inside the server. Then the procedure's 
return value (if any) goes through the same process in reverse, ending 
up at the client end just like a normal procedure call.

Oh, and there's optional authentication, encryption, asynchronous 
messaging, message queues (but only in Windows 2000, no other OS), and a 
bunch of other stuff that didn't make sense.

- COM allows you to create objects, find out what interfaces they 
support, and call the functions in those interfaces. These objects can 
be provided by a DLL loaded into your program, an EXE running on the 
same computer, or (hypothetically) a program running on some remote 
computer. So it's like a system that can DLL procedure calls or RPC 
calls - and you don't have to care which.

Again, I haven't actually figured out how to *call* a COM method. I have 
however figured out how to create an object, find out what interfaces it 
has, and get hold of the one you want. What I can't find anything about 
is how you get from having the interface to calling one of the methods 
it contains...

...it all seems like a hell of a lot of work just to write a PNG file. 
Maybe it would be quicker (and more portable) to just read the PNG file 
spec and write my own encoder? (Except that, well, have you *seen* the 
algorithm?! Complicated, much??)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

> - COM allows you to create objects, find out what interfaces they 
> support, and call the functions in those interfaces. These objects can 
> be provided by a DLL loaded into your program, an EXE running on the 
> same computer, or (hypothetically) a program running on some remote 
> computer. So it's like a system that can DLL procedure calls or RPC 
> calls - and you don't have to care which.

Incidentally, I found out why the registry is called... the registry.

It's where you *register* where the hell the code for all these objects 
is actually stored. Who'd have thought?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> But of *course*, if you're writing new software, you will only be 
> interested in making it work for Windows 7 (which, I add, isn't even 
> available yet).

Of course it's available. Not the release version, but the betas.

> Why would you want to target the OS that 99% of your 
> market is still using when you could target some brand new unreleased 
> one and thus force everybody to actually buy it?

It's not *that* hard to figure out which 2% of the features in the OS are 
new to Windows 7 and which are the same stuff that's been around for 5+ years.

> After spending a couple of hours on this, here's what I managed to 
> figure out:
> 
> - A DLL is a file containing a set of procedures. You can dynamically 
> load it into memory and call these procedures. (I'm not precisely sure 
> how...)

Yes. It's a dynamically-linked library. Says it right there in the name. :-)

In the beginning of the file is a table of names and pointers. You can look 
up the name to get the pointer, or you can just branch indirectly thru the 
pointer if you know at compile time its offset.

http://en.wikipedia.org/wiki/Dynamic-link_library

> - RPC is both a network protocol and a system for calling procedures in 
> another running program. This program may or may not be running on the 
> same computer.

Well, RPC is a generic term, meaning to invoke a procedure in someone else's 
address space. Sun took the term and used it to refer to their particular 
implementation. Ever since, "RPC" has been like "PC" - do you mean Personal 
Computer or an IBM compatible machine running MS-DOS?

> As best as I can tell, you write a list of procedures that you want to 
> be able to call remotely, and run this through the MIDL compiler. This 
> spits out two blobs of code. You link one into your client, and it 
> enables you to call these procedures just like any other procedure. 

Right. Actually, not quite right. What it spits out is a description of the 
COM interface. Then your compiler takes that description and generates the 
actual code to call it. It's not some secret code. It's a well-defined 
interface that any compiler can implement. Heck, I can call it from Tcl.

> However, what the generated code actually does is scoop up the 
> parameters passed, serialise them somehow, and then presumably call some 
> secret undocumented Win32 function to actually send this data somewhere. 

Yes. Because the best way to promote everyone to use your technology is to 
not document how to incorporate it into your code.

Sheesh.

Even *wikipedia* documents what the calls are. Why would you think it's secret?

> The data is then sent either via local IPC or network RPC packets to the 
> server side.

Yes.

> The code blob linked into the server then unserialises the data and 
> calls the actual procedure inside the server. Then the procedure's 
> return value (if any) goes through the same process in reverse, ending 
> up at the client end just like a normal procedure call.

Basically, yes.

> Oh, and there's optional authentication, encryption, asynchronous 
> messaging, message queues (but only in Windows 2000, no other OS), and a 
> bunch of other stuff that didn't make sense.

Everything from Windows 2000 on, which I believe is where they introduced 
DCOM.  Regular COM, where you're calling a different process on the same 
machine, obviously doesn't need authentication, encryption, etc.

> - COM allows you to create objects, find out what interfaces they 
> support, and call the functions in those interfaces. These objects can 
> be provided by a DLL loaded into your program, an EXE running on the 
> same computer, or (hypothetically) a program running on some remote 
> computer. So it's like a system that can DLL procedure calls or RPC 
> calls - and you don't have to care which.

Exactly. Plus, it's an active object, i.e., what people call an "Actor". A 
process running Excel is basically one big COM object, with methods like 
"open a spreadsheet" and "return the value of column B row 27." That's how 
people do these automation tasks.

> Again, I haven't actually figured out how to *call* a COM method.

You can use IDispatch::Invoke for dynamically linked stuff.

http://msdn.microsoft.com/en-us/library/ms690156(VS.85).aspx

http://en.wikipedia.org/wiki/IDispatch

http://msdn.microsoft.com/en-us/library/ms221479.aspx

I'll grant you, that one was a bit ugly. :-)


> ...it all seems like a hell of a lot of work just to write a PNG file. 

Only because your language doesn't already have COM in it. Once you get the 
basics worked out, then you can say "How do I convert an Excel spreadsheet 
to a pie chart as a GIF file" and do it with the same code.

Most programming languages have the COM stuff already built for them (which 
is kind of the poing of making it standard, see) so it's just a matter of 
invoking the component.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Orchid XP v8 schrieb:
> ...it all seems like a hell of a lot of work just to write a PNG file. 
> Maybe it would be quicker (and more portable) to just read the PNG file 
> spec and write my own encoder? (Except that, well, have you *seen* the 
> algorithm?! Complicated, much??)

Why not just go grab libpng? That's how POV-Ray does it.

Post a reply to this message

Orchid XP v8 wrote:
> So now I'm wondering if Windows provides any easy way to load and save 
> bitmapped images. GDI appears to allow you to load and save in Windows 
> Bitmap format - arguably amoung the worst file formats *ever*. But what 
> about something more sane?

Look for GDI+ It's applicable to Windows XP and higher. It's 
object-oriented, and designed to work with C++, iirc, so will need C++ 
in order to use it, though I think they have C wrappers.

> 
> ...so now I'm trying to figure out what the hell COM is. :-/
> 

Component Object Model ;)

Essentially it was supposed to be a cross-language way of dealing with 
things in an object-oriented manner. It looks very intimidating at 
first, but once you get the hang of it, it's really not too bad. 
Building the C/C++ headers from the IDL files is rather easy using the 
#import directive, though some have dependencies you'll have to import 
as well.

Have fun ;) I did this sort of programming for quite a long time, both 
on the component side, and the application side.

Post a reply to this message

>> ...it all seems like a hell of a lot of work just to write a PNG file. 
> 
> Why not just go grab libpng? That's how POV-Ray does it.

Isn't that a DLL?

So... I'd *still* need to figure out how DLLs work. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>> But of *course*, if you're writing new software, you will only be 
>> interested in making it work for Windows 7 (which, I add, isn't even 
>> available yet).
> 
> Of course it's available. Not the release version, but the betas.

They have a beta already? Damn, that was fast...

>> Why would you want to target the OS that 99% of your market is still 
>> using when you could target some brand new unreleased one and thus 
>> force everybody to actually buy it?
> 
> It's not *that* hard to figure out which 2% of the features in the OS 
> are new to Windows 7 and which are the same stuff that's been around for 
> 5+ years.

Actually, MSDN does a surprisingly good job of documenting this 
information, yes.

>> - A DLL is a file containing a set of procedures. You can dynamically 
>> load it into memory and call these procedures. (I'm not precisely sure 
>> how...)
> 
> Yes. It's a dynamically-linked library. Says it right there in the name. 
> :-)

In other words, it's a shared library. I more or less knew they before. ;-)

> In the beginning of the file is a table of names and pointers. You can 
> look up the name to get the pointer, or you can just branch indirectly 
> thru the pointer if you know at compile time its offset.

I just meant I haven't found the actual function call for getting access 
to the exposed symbols yet.

(According to Wikipedia, seems to be GetProcAddress()...)

>> - RPC is both a network protocol and a system for calling procedures 
>> in another running program. This program may or may not be running on 
>> the same computer.
> 
> Well, RPC is a generic term, meaning to invoke a procedure in someone 
> else's address space. Sun took the term and used it to refer to their 
> particular implementation. Ever since, "RPC" has been like "PC" - do you 
> mean Personal Computer or an IBM compatible machine running MS-DOS?

Sure. But in this case, I'm talking about Microsoft RPC. As in, that 
service that if it stops running, your entire PC shuts down for some 
reason... (MS Blaster, anyone?)

>> As best as I can tell, you write a list of procedures that you want to 
>> be able to call remotely, and run this through the MIDL compiler. This 
>> spits out two blobs of code. You link one into your client, and it 
>> enables you to call these procedures just like any other procedure. 
> 
> Right. Actually, not quite right. What it spits out is a description of 
> the COM interface. Then your compiler takes that description and 
> generates the actual code to call it. It's not some secret code. It's a 
> well-defined interface that any compiler can implement. Heck, I can call 
> it from Tcl.

I'm not quite following.

According to the documentation, you write an MIDL file, and the compiler 
generates a header file and two C source code files. You link one into 
the client, and one into the server. (I haven't tried it, so I don't 
know what's actually *in* these C files, mind you...)

>> However, what the generated code actually does is scoop up the 
>> parameters passed, serialise them somehow, and then presumably call 
>> some secret undocumented Win32 function to actually send this data 
>> somewhere. 
> 
> Yes. Because the best way to promote everyone to use your technology is 
> to not document how to incorporate it into your code.
> 
> Sheesh.
> 
> Even *wikipedia* documents what the calls are. Why would you think it's 
> secret?

Because the MIDL compiler generates this code, so technically you don't 
need to know how it actually works. (Also, I couldn't find any functions 
anywhere which looked likely.)

>> The data is then sent either via local IPC or network RPC packets to 
>> the server side.
> 
> Yes.
> 
>> The code blob linked into the server then unserialises the data and 
>> calls the actual procedure inside the server. Then the procedure's 
>> return value (if any) goes through the same process in reverse, ending 
>> up at the client end just like a normal procedure call.
> 
> Basically, yes.
> 
>> Oh, and there's optional authentication, encryption, asynchronous 
>> messaging, message queues (but only in Windows 2000, no other OS), and 
>> a bunch of other stuff that didn't make sense.
> 
> Everything from Windows 2000 on, which I believe is where they 
> introduced DCOM.  Regular COM, where you're calling a different process 
> on the same machine, obviously doesn't need authentication, encryption, 
> etc.

I'm reasonably sure NT 4 has DCOM, but possibly with NTLM authentication 
only. Windows 2000 is where they added Kerberos, for sure.

>> - COM allows you to create objects, find out what interfaces they 
>> support, and call the functions in those interfaces. These objects can 
>> be provided by a DLL loaded into your program, an EXE running on the 
>> same computer, or (hypothetically) a program running on some remote 
>> computer. So it's like a system that can DLL procedure calls or RPC 
>> calls - and you don't have to care which.
> 
> Exactly. Plus, it's an active object, i.e., what people call an "Actor". 

...you mean the object can be doing other stuff by itself before you 
specifically ask it to do something?

> A process running Excel is basically one big COM object, with methods 
> like "open a spreadsheet" and "return the value of column B row 27." 
> That's how people do these automation tasks.

Heh. I had always assumed that such tasks are simply impossible, because 
I've never come across a programming language that can do them. (Well, 
except VB. And who the hell understands that?)

>> Again, I haven't actually figured out how to *call* a COM method.
> 
> You can use IDispatch::Invoke for dynamically linked stuff.
> 
> http://msdn.microsoft.com/en-us/library/ms690156(VS.85).aspx
> 
> http://en.wikipedia.org/wiki/IDispatch
> 
> http://msdn.microsoft.com/en-us/library/ms221479.aspx
> 
> I'll grant you, that one was a bit ugly. :-)

But, uh, isn't IDispatch::Invoke *itself* a COM method??

Seriously, I see CoInitialise() and CoUninitialise() to start/stop the 
COM library. I see CoGetClassObject() and CoCreateInstanceEx(), but I 
can't see a CoCallMethod() or similar anywhere.

>> ...it all seems like a hell of a lot of work just to write a PNG file. 
> 
> Only because your language doesn't already have COM in it. Once you get 
> the basics worked out, then you can say "How do I convert an Excel 
> spreadsheet to a pie chart as a GIF file" and do it with the same code.
> 
> Most programming languages have the COM stuff already built for them 
> (which is kind of the poing of making it standard, see) so it's just a 
> matter of invoking the component.

Well, maybe I need to sit down and spend some time creating "COM 
support" for Haskell, and then everything will become trivial. :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

>>> ...it all seems like a hell of a lot of work just to write a PNG file. 
>>
>> Only because your language doesn't already have COM in it.
> 
> Well, maybe I need to sit down and spend some time creating "COM 
> support" for Haskell, and then everything will become trivial. :-P

Well well, it appears there's already a library on Hackage that's 
supposed to provide COM support.

Oh, would you look at that? It won't compile. What a *big* surprise...

They really, really need to make it so that packages that call C will 
actually compile on Windoze. :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message