 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 20 Sep 2009 16:24:57 +0200, Orchid XP v8 <voi### [at] dev null> 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.
>
> They have a beta already? Damn, that was fast...
Actually, the RTM (Release-To-Market) version was finished a couple of
months ago and was made available through MSDN and the like on August 6th.
It is scheduled to hit stores on October 22nd.
--
FE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
> (According to Wikipedia, seems to be GetProcAddress()...)
>
> 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.
That's because from C, you call the methods directly via their procedure
addresses - which, as Wikipedia correctly claims, you get via
GetProcAddress().
So you'd need to declare a function pointer to whatever type it should
be according to the COM object's interface definition, assign it a value
via GetProcAddress(), and then invoke that function pointer just like
you would invoke any other function.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
> They really, really need to make it so that packages that call C will
> actually compile on Windoze. :-P
... especially if that package is intended to provide COM support, which
doesn't make much sense on other platforms anyway :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
>> 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. ;-)
Here's good news for you: You can compile libpng as a static lib, too -
POV-Ray actually does that (at least on Windows).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> They have a beta already? Damn, that was fast...
No, the beta is already *expired*. :-)
>> 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. ;-)
Not necessarily shared. Just dynamically linked. It happens that on Windows
(and Linux, as far as I know) that such libraries are indeed shared. But you
can have dynmamic linking without sharing and you can have sharing without
dynamic linking.
> (According to Wikipedia, seems to be GetProcAddress()...)
Yes.
> 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?)
It shuts down because huge amounts of the OS are built premised on the
availability of COM. It doesn't completely shut down, of course, but
everything *interesting* does.
> According to the documentation, you write an MIDL file, and the compiler
> generates a header file and two C source code files.
It generates a TBL file, which your tool then reads to generate whatever
language-specific bindings you want.
> Because the MIDL compiler generates this code, so technically you don't
> need to know how it actually works.
A) No it doesn't. It also generates a TBL file.
B) You'd have to know how it works to interface it to any language not
written in C.
> I'm reasonably sure NT 4 has DCOM,
Could be, could be.
>> 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?
Yes. As I said, "Excel" is a COM object. It's running in a separate process.
That's why it's not just a DLL.
>> 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?)
*Every* language can do it. I've done it from Tcl (as well as writing COM
servers). It's trivial from C# and as trivial as anything is in C, and VB,
and WSH. Like I said, WSH is basically a shell designed to do nothing but
COM calls.
> 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.
Hmmm. Well, ship me the two C files from your MIDL, and I'll tell you what
the call it. :-)
> Well, maybe I need to sit down and spend some time creating "COM
> support" for Haskell, and then everything will become trivial. :-P
That's the general idea, yes.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> ... especially if that package is intended to provide COM support, which
> doesn't make much sense on other platforms anyway :-P
Cross-OS DCOM is actually pretty handy. I did that once to parse Excel
spreadsheets from Linux servers.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Cross-OS DCOM is actually pretty handy. I did that once to parse Excel
> spreadsheets from Linux servers.
Yeah, MS asserts that COM is usable on other platforms as well. Anybody
know how you actually do this?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Yeah, MS asserts that COM is usable on other platforms as well.
I think what they mean is that COM, in *theory*, can be ported to other
platforms. In much the same way that .NET can be reimplemented on other
platforms.
> Anybody know how you actually do this?
We had to write dcom libraries to link to Tcl to do this. It was pretty
ugly, and very fragile.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Yeah, MS asserts that COM is usable on other platforms as well.
>
> I think what they mean is that COM, in *theory*, can be ported to other
> platforms. In much the same way that .NET can be reimplemented on other
> platforms.
The documentation seems to suggest that MS COM is based on some
open-standard COM with a few extensions, and that it's *supposed* to
interoperate with other implementations of that standard.
(Admittedly, if it's anything like IE and its "standards", this won't be
much fun...)
>> Anybody know how you actually do this?
>
> We had to write dcom libraries to link to Tcl to do this. It was pretty
> ugly, and very fragile.
Heh. Fun.
Give me ARexx any day. :-P
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> The documentation seems to suggest that MS COM is based on some
> open-standard COM with a few extensions, and that it's *supposed* to
> interoperate with other implementations of that standard.
I see. The number of "standard" implementations of the same idea is tremendous.
> (Admittedly, if it's anything like IE and its "standards", this won't be
> much fun...)
To be fair, a lot of what IE does was done before the post-hoc standards
were written. Backward compatibility is a bitch.
> Give me ARexx any day. :-P
Agreed. That was pretty cool.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The documentation seems to suggest that MS COM is based on some
>> open-standard COM with a few extensions, and that it's *supposed* to
>> interoperate with other implementations of that standard.
>
> I see. The number of "standard" implementations of the same idea is
> tremendous.
It's meant to be an extension of DCE RPC. (Indeed, I recall Ethereal
used to mark the packets as such...)
>> (Admittedly, if it's anything like IE and its "standards", this won't
>> be much fun...)
>
> To be fair, a lot of what IE does was done before the post-hoc standards
> were written. Backward compatibility is a bitch.
Heh. And yet, IE6 is still horribly broken, years after those standards
were written.
>> Give me ARexx any day. :-P
>
> Agreed. That was pretty cool.
...although possibly not for exchanging large quantities of data, or
doing crazy stuff like embedding one document inside another. But for
simple scripting, it sure made everything... simple.
Still, maybe WSH does the same.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Heh. And yet, IE6 is still horribly broken, years after those standards
> were written.
But IE6 is following the standards from the earlier IEs. In other words, IE8
*still* follows the original netscape cookie spec, for example, rather than
the new improved W3C spec, because there are dumb-ass programmers who think
that if it works, it must be right.
> Still, maybe WSH does the same.
It does.
--
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:
>>
>> To be fair, a lot of what IE does was done before the post-hoc
>> standards were written. Backward compatibility is a bitch.
>
> Heh. And yet, IE6 is still horribly broken, years after those standards
> were written.
>
No surprise, given that it's obsolete since two version increments :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Of course it's available. Not the release version, but the betas.
Surely developers already have the release version to test everything is ok?
I mean it's one month now until it goes on sale.
> They have a beta already? Damn, that was fast...
The betas have been out for *ages*.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> 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...
So I asked the "vibrant Haskell community" about this. (Yes, the Haskell
community that's supposedly one of the strongest selling points of the
language.) Wanna take a guess how many people have bothered to reply?
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?
>
Are you using .NET or VB6?
You can download .NET express for free
http://www.microsoft.com/express/vb/Default.aspx
I am currently working an application in .NET that works with image
files (.BMP, .JPG, .PNG) - displays them, draws on them and saves them.
I've done it in both - without too much trouble and without DLL
hell.
.net - almost directly copied out of my application
colors a point
draws a rectangle
this is on a image in memory - it is not visible to the user
just assign the image to a image control to see it
********************************
********************************
********************************
Private MasterImage As Bitmap
MasterImage = New Bitmap(imageFilePath, False)
MasterImage.SetPixel(x, y, Color.CornflowerBlue)
Dim graphicsDrawer As Graphics
graphicsDrawer = Graphics.FromImage(MasterImage)
Dim penZoomLines As New Pen(Color.YellowGreen, 1)
penZoomLines.DashStyle = Drawing2D.DashStyle.Dash
Dim zoomRectangle As Rectangle
zoomRectangle.X = (FullCoords.Width / MasterImage.Width) * ZoomCoords.X
zoomRectangle.Y = 0
zoomRectangle.Width = (FullCoords.Width / MasterImage.Width) *
ZoomCoords.Width
zoomRectangle.Height = FullCoords.Height
graphicsDrawer.DrawRectangle(penZoomLines, zoomRectangle)
MasterImage.Save("test.png", System.Drawing.Imaging.ImageFormat.Png)
********************************
********************************
********************************
Good luck getting your app going.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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?
>
> Are you using .NET or VB6?
Nope. I'm using Haskell, everybody's favourit programming language.
Of course, you *can* quite easily load and save PNG or JPEG from
Haskell. If you have GTK+ installed. No problem on Linux, but kinda
unusual for Windoze. Oh, it *works* just fine. But it means anybody who
wants to run your program needs GTK+ installed. Actually, not even
installed, just the DLLs really. But there's about 20MB of them!
There's also a binding to something called "GD" which is supposed to do
something similar.
I suppose the ultimate answer would be to write a native Haskell PNG
codec. Then it will run everywhere Haskell does.
Looks like figuring out this COM stuff might also conceivably work... I
guess we'll see, assuming anybody ever gets back to me about how to make
the library compile.
Aside: The Haskell GTK+ binding has full support for both bitmapped
graphics and vector graphics. Vector drawing uses Cairo, and is really
delightfully easy to use. It can render to the screen, to memory, or to
a file in one of several formats (PNG / JPEG / SVG / PDF / PS).
The bitmapped graphics... involves manipulating the low-level bitmap
manually, all by yourself. This is *not* my idea of a fun time. Also, it
took about a week of wading through the API to figure out how to work it.
In other words, vector graphics is very easy, bitmapped graphics is
quite hard. So I wrote a library to make it easy. Now you can easily
load and save bitmaps, and read or write pixels in them. One of my
better achievements. But, as I say, you have to have GTK+ for it to work...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible 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?
>>
>> Are you using .NET or VB6?
>
> Nope. I'm using Haskell, everybody's favourit programming language.
>
sorry, i guess i missed something
BTW, you may like this news
http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible schrieb:
> So I asked the "vibrant Haskell community" about this. (Yes, the Haskell
> community that's supposedly one of the strongest selling points of the
> language.) Wanna take a guess how many people have bothered to reply?
Hm... a single one, who promptly got stoned for that? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Are you using .NET or VB6?
>>
>> Nope. I'm using Haskell, everybody's favourit programming language.
>
> sorry, i guess i missed something
No need to be sorry for trying to help. ;-)
> BTW, you may like this news
> http://tommd.wordpress.com/2009/09/13/kernel-modules-in-haskell/
Yeah, a few people have pointed this one out already.
The "House" they keep referring to was an entire OS written in pure
Haskell. (At least, as far as Linux is an OS written in pure C - i.e.,
there are some small fragments of assembly as well.) All these guys have
done is taken the work from House and adapted it to work with a standard
Linux kernel. (I say "all" as if it's a small thing, but I'm just saying
somebody else already did a lot of the heavily lifting.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> To be fair, a lot of what IE does was done before the post-hoc
>>> standards were written. Backward compatibility is a bitch.
>>
>> Heh. And yet, IE6 is still horribly broken, years after those
>> standards were written.
>
> No surprise, given that it's obsolete since two version increments :-P
Let me just go check... Yep, my PC has IE6 installed.
Wanna guess how many other people also?
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Wanna take a guess how many people have bothered to reply?
>
> Hm... a single one, who promptly got stoned for that? :-P
Er, actually zero.
That's the thing about Haskell. If you pop in and say "what the heck
does 'monad' mean?" you'll get about 25 replies in less than 60 seconds.
(NO I AM NOT EXAGGERATING! I've seen it happen *so many* times.)
Actually, for THAT question, most of the replies will be "read this
reference manual / blog post / text book". But if you ask something
slightly less commonly asked, you'll get 25 people explain it to you 25
different ways - one of which will hopefully make some sort of sense to you.
But, if you ask a question such as "why doesn't this work on Windows?"
you will be greeted by deathly silence. Indeed, there are whole classes
of questions which nobody will answer.
So basically, if you're a newbie and you're asking "easy" questions,
you'll get a flood of replies and quickly conclude that Haskell has a
vibrant and friendly community behind it. But as soon as you start
asking "difficult" or just "uninteresting" questions... you'll form
another opinion. *sigh*
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 21 Sep 2009 19:32:46 +0100, Orchid XP v8 wrote:
> But, if you ask a question such as "why doesn't this work on Windows?"
> you will be greeted by deathly silence. Indeed, there are whole classes
> of questions which nobody will answer.
Maybe nobody knows.....
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> But, if you ask a question such as "why doesn't this work on Windows?"
>> you will be greeted by deathly silence. Indeed, there are whole classes
>> of questions which nobody will answer.
>
> Maybe nobody knows.....
While that *is* quite likely, it's also quite unhelpful.
Well anyway, I threatened them with http://www.bash.org/?152037 and now
I seem to be getting useful hints at least. (Stuff like "turn on debug
logging".)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 schrieb:
>>> Heh. And yet, IE6 is still horribly broken, years after those
>>> standards were written.
>>
>> No surprise, given that it's obsolete since two version increments :-P
>
> Let me just go check... Yep, my PC has IE6 installed.
>
> Wanna guess how many other people also?
Yeah, but I guess not many of them expect IE6 to get any better nowadays :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 21 Sep 2009 20:01:02 +0100, Orchid XP v8 wrote:
>>> But, if you ask a question such as "why doesn't this work on Windows?"
>>> you will be greeted by deathly silence. Indeed, there are whole
>>> classes of questions which nobody will answer.
>>
>> Maybe nobody knows.....
>
> While that *is* quite likely, it's also quite unhelpful.
That's the nature of online support. People who don't know don't speak
up because they don't feel they can contribute anything by saying "I have
no idea".
> Well anyway, I threatened them with http://www.bash.org/?152037 and now
> I seem to be getting useful hints at least. (Stuff like "turn on debug
> logging".)
Heh, funny, but in reality that doesn't work either. We get that on the
openSUSE forums (where I'm now a moderator) occasionally, and the typical
troll is "Linux sux and I'm moving back to windows", which gets the
response "Have a lot of fun!" (A tagline of sorts for SUSE).
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well anyway, I threatened them with http://www.bash.org/?152037 and now I
> seem to be getting useful hints at least. (Stuff like "turn on debug
> logging".)
It often seems to work. Usually along the lines of "OS/program/API X sucks
because it can't do Y", followed shortly by "GIYF/MSDN/help is your friend,
actually you can do Y like this...".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Henderson wrote:
> That's the nature of online support. People who don't know don't speak
> up because they don't feel they can contribute anything by saying "I have
> no idea".
You haven't spent much time hanging around p.o-t, have you? ;-)
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 22 Sep 2009 09:50:19 -0700, Darren New wrote:
> Jim Henderson wrote:
>> That's the nature of online support. People who don't know don't speak
>> up because they don't feel they can contribute anything by saying "I
>> have no idea".
>
> You haven't spent much time hanging around p.o-t, have you? ;-)
Hehehehehe, arguably, p.o-t isn't exactly a support area. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> You haven't spent much time hanging around p.o-t, have you? ;-)
>
> Hehehehehe, arguably, p.o-t isn't exactly a support area. ;-)
I think of it as more of a group therapy area, but whatever...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 22 Sep 2009 19:26:04 +0100, Orchid XP v8 wrote:
>>> You haven't spent much time hanging around p.o-t, have you? ;-)
>>
>> Hehehehehe, arguably, p.o-t isn't exactly a support area. ;-)
>
> I think of it as more of a group therapy area, but whatever...
LOL
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-9-2009 20:26, Orchid XP v8 wrote:
>>> You haven't spent much time hanging around p.o-t, have you? ;-)
>>
>> Hehehehehe, arguably, p.o-t isn't exactly a support area. ;-)
>
> I think of it as more of a group therapy area, but whatever...
>
I think of it as more *your* group therapy area.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I think of it as more of a group therapy area, but whatever...
>>
> I think of it as more *your* group therapy area.
Well, I *am* the nominated forum mascot...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 22-9-2009 23:00, Orchid XP v8 wrote:
>>> I think of it as more of a group therapy area, but whatever...
>>>
>> I think of it as more *your* group therapy area.
>
> Well, I *am* the nominated forum mascot...
>
I know and I do like the reversal of roles here. Normally a mascot is
there to motivate the team.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 22 Sep 2009 23:11:19 +0200, andrel wrote:
> On 22-9-2009 23:00, Orchid XP v8 wrote:
>>>> I think of it as more of a group therapy area, but whatever...
>>>>
>>> I think of it as more *your* group therapy area.
>>
>> Well, I *am* the nominated forum mascot...
>>
> I know and I do like the reversal of roles here. Normally a mascot is
> there to motivate the team.
Arguably, we are motivated...to help Andy. ;-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Arguably, we are motivated...to help Andy. ;-)
It's like Everest... People seem to want to see if they can get Andy to
stop failing so epically.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 23 Sep 2009 09:12:41 +0100, Invisible wrote:
>> Arguably, we are motivated...to help Andy. ;-)
>
> It's like Everest... People seem to want to see if they can get Andy to
> stop failing so epically.
Fear is the mind-killer.... :-)
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
