rle extension
#42
Posted 12 November 2005 - 08:51 PM
( your PROC ) to an out-of-process ( that's Microsoft's WLM ) to it's resource
memory or the image memory . The indirection of the RLE compression and the
changing of the image attributes while in transition will not be available to ( your PROC ).
There would have to be an ( Mutually Inclusive Privileged ) integrated within an ( IPC )
between the 2 ( PROC's ) for this to be established. It's true that you can acquire a handle
to a specified out-of-proc window control but that doesn't gain the access to the 4g allocated
to the other PROC's process.
Can skinning be done based off of what has been discussed, YES.
But when I set out to try a look at this original request I found that my solution BREAKS
Microsoft's EULA for MSN or WLM messenger's. Whether or not it was Microsoft's code or
someone elses, this just ain't ethically Professional much less against the standard laws to
anyone's EULA. Just because a developer can do the requested doesn't give one the ability
to take advantage of another person's software property or rights.
Right before my posting this I seen this comment in another forum just posted today:
Quote
IMO, something is terrible wrong with the actions of others and should not be supported on
msnfanatic.com for all to assume - Go Ahead - Nobody Cares.
I hope that no one get upset with my conculsion about this subject.
I personally should have thought this out in the early beginnings of my
comments and well before making them, in regards to this subject of skinning.
TheBlasphemer, I owe you an appology for my enticing words to set you off
in regards to the beginning. Oh man, sometimes I just should keep my comments
to myself. I enjoy my development projects and sometimes helpful notations
but not like that of my current expressions.
Everyone should take a serious look at Microsoft's EULA for MSN or WLM messenger's.
If you can't honor Microsoft's rights, then who will you pay honor to?
Respectfully,
LipoToid
#45
Posted 16 November 2005 - 02:09 PM
So, has anyone made any progress on the topic of decoding the RLE format?
I'll remain positive :) , until im given reason otherwise.
-The Unknown
This post has been edited by theunknown: 16 November 2005 - 02:10 PM
#46
Posted 18 December 2005 - 03:27 PM
Also would changing the ufiles to idres=blah again would that help include pngs?
#47
Posted 19 December 2005 - 03:21 AM
as for the link... we've established its not standard Run-Length-Encoding, we need to find out what has been changed in the algorithm.
-The Unknown
This post has been edited by theunknown: 19 December 2005 - 03:23 AM
#48
Posted 19 December 2005 - 04:38 AM
TheSteve as I see that you are reading this thread, perhaps you can help us. I think our answer might also lie in decrypting the highcont.thm file.
@dogge: want to please give me a copy of your resource editing tool :)
This post has been edited by ipab: 19 December 2005 - 04:40 AM
#51
Posted 19 December 2005 - 09:41 AM
ipab, on Dec 19 2005, 01:49 PM, said:
As far as I can tell, currently it doesn't load that module, but yes, I imagine in the future I can be used for skinning.
Here's some of what I've found out so far:
MSN loads ?CreateRLE@Value@DirectUI@@SGPAV12@PBX@Z from MSNCORE.dll
This function can be interpreted like this:
DirectUI::Value * DirectUI::Value::CreateRLE(void const *)
Inside the CreateRLE call, it calls a function at MSNCore.59116AFB which seems to call TlsGetValue with the value from "?g_dwElSlot@DirectUI@@3KA" (unsigned long DirectUI::g_dwElSlot).
This value seems to always be 0x20.
The return of this function looks like (TlsGetValue(g_dwElSlot)+8).
After it returns (we are still in CreateRLE) it calls "?Alloc@SBAlloc@DirectUI@@QAEPAXXZ" (void * DirectUI::SBAlloc::Alloc(void)).
This function, I assume allocates memory for the Value object.
After that function it appears to do some binary operations.
MOV ECX,DWORD PTR SS:[EBP+0x8] ;EBP+8 is the first parameter (in this case it's the "RLE" data) AND BYTE PTR DS:[EAX+0x10],0xFE ;EAX is the return value from the Alloc function ;0FE and 10 are both HEX MOV WORD PTR DS:[EAX+0x4],0x10 MOV DWORD PTR DS:[EAX+0xC],ECX MOV DWORD PTR DS:[EAX+0x8],0x1
After that it returns from the CreateRLE function. So now we have a pointer to the Value object, but since we don't have any real information on this object, what do we do from here? Ideas?
#52
Posted 20 December 2005 - 04:05 PM
A: We have gotten a postive and negative feedback on the UI. We are looking at making it better. Keep the feedback coming.
that is what one of the msn team said, so can we expect a full skinable program to be made instead of patching?
#53
Posted 20 December 2005 - 05:08 PM
<offtopic> That chat was a worthless P.O.S. None of our realy questions seemed to be answered, all they kept saying was "Good idea, thanks for your suggestion".
</offtopic>
btw Steve, do you have a wlm invite.
This post has been edited by ipab: 20 December 2005 - 05:16 PM
#54
Posted 21 December 2005 - 05:13 AM
so its off to the newsgroups for me to try and get somewhere there and give some suggestions :)

Sign In
Register
Help
This topic is locked
MultiQuote