>>> I still think recording a few keypresses and doing some statistics on 
>>> them is way, way simpler.
>> 
>> Since when do you take the simpler solution? :-)
> 
> What you trying to say? :-P

That you often seem up for a challenge :-D

Post a reply to this message

>> What you trying to say? :-P
> 
> That you often seem up for a challenge :-D

I enjoy challenges that I have some hope of beating. Trying to do 
something impossible isn't a challenge, it's a guaranteed defeat. Losing 
isn't fun.

Post a reply to this message

On 6/7/2010 9:50 AM, Darren New wrote:

>
> Hey, at least he didn't say it's obviously impossible. :-)
>

LOL

-- 
~Mike

Post a reply to this message

On 6/8/2010 1:51 AM, scott wrote:

> Funny how it took me about 30 mins of research and coding to come up
> with a working program, when previously I didn't know a single thing
> about it. It didn't require any skills beyond being able to set up a
> struct and calling windows API functions. In my book ludicrously
> difficult is when I think and work on something for *weeks* or *months*
> and cannot get anywhere close to a working program.

Nah, somewhat difficult is dealing with OLE objects on the clipboard, 
but that's mainly because of the special memory allocator requirements, 
serialization and marshaling requirements.

Rather difficult is writing an Dispatch interface with no framework.

Ludicrously difficult is programming in machine code for a processor 
that doesn't yet exist's micro-ops. ;)

-- 
~Mike

Post a reply to this message

On 6/8/2010 3:03 AM, Invisible wrote:

> Oh, wait - you'd need a hex editor to do that...

I hear there's a nice one coming out ... some time. Written by a member 
of this newsgroup, too!


-- 
~Mike

Post a reply to this message

>> Oh, wait - you'd need a hex editor to do that...
> 
> I hear there's a nice one coming out ... some time. Written by a member 
> of this newsgroup, too!

Yeah, there is. Just as soon as I finish writing it. :-P

Post a reply to this message

> Ludicrously difficult is programming in machine code for a processor 
> that doesn't yet exist's micro-ops. ;)

That depends on how complex the processor is, now doesn't it? ;-)

Post a reply to this message

On 6/8/2010 3:31 AM, Invisible wrote:
>
> (Unless, of course, you're working with a language which actually has
> built-in support for calling DLLs. Then presumably it *is* trivial.)
>

Any language that uses the pascal calling convention or allows the use 
of the pascal calling convention has built in support for calling at 
least the system DLL's (results may vary with others, especially C++ 
dlls that use name mangling and thiscall calling convention. But, if you 
can emit machine code, you're golden. ;) Just load ECX or RCX with the 
target's address push the arguments on the stack (in the proper order) 
and you're golden. ;)

>> So long as your language allows you to set up a block of data with the
>> common data types it shouldn't be at all tricky.
>
> Heh, right.
>
> I still think recording a few keypresses and doing some statistics on
> them is way, way simpler.


-- 
~Mike

Post a reply to this message

>> (Unless, of course, you're working with a language which actually has
>> built-in support for calling DLLs. Then presumably it *is* trivial.)
> 
> Any language that uses the pascal calling convention or allows the use 
> of the pascal calling convention has built in support for calling at 
> least the system DLL's.

Dude, that's like saying...

> But, if you can emit machine code, you're golden. ;)

...oh god.

Hey, you know there are people who solved the Project Euler problems 
using only assembly, right? :-P

Post a reply to this message

On 6/8/2010 7:41 AM, Invisible wrote:

> Hey, you know there are people who solved the Project Euler problems
> using only assembly, right? :-P

I'm sure there are... Say! That sounds like a really fun challenge!

-- 
~Mike

Post a reply to this message