flat assembler
Message board for the users of flat assembler.

Index > Windows > Patching system dlls

Goto page Previous  1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
DC740



Joined: 01 Oct 2004
Posts: 74
Location: Argentina
DC740
i've been following this topic from the begining and I'm really interested.... why don't you start a complete project???, i've seen that there are a few people patching and improving microsoft dlls, not only one...
i don't have the knowledge to take part of this project, but i would be very interested and i can tell you that i would be the first tester!!! Razz

it's just an idea... a web page dedicated to modified dlls with speed improvements...

good bye and happy coding
Post 11 Dec 2005, 17:15
View user's profile Send private message Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
Is there any such project somewhere on the web?
Post 11 Dec 2005, 18:13
View user's profile Send private message Visit poster's website Reply with quote
DC740



Joined: 01 Oct 2004
Posts: 74
Location: Argentina
DC740
i didn't find any, and going back to the topic, it's true, the only way to patch system dlls is copying the patched dll to the dll cache directory...

http://www.windowsnetworking.com/articles_tutorials/Tweaking-XP-Windows-File-Protection-SP2.html

good bye n happy coding
Post 11 Dec 2005, 19:48
View user's profile Send private message Reply with quote
lilljocke



Joined: 28 Dec 2004
Posts: 34
Location: Sweden
lilljocke
Hi

I very interested in this project. I'm codeing a program that can make a "system dll patcher" program. i hope that it can help you

Is the 64 bit version more secure? i mean if it use the same funtion as the 32 bit?
Post 12 Dec 2005, 01:40
View user's profile Send private message Visit poster's website Reply with quote
Matrix



Joined: 04 Sep 2004
Posts: 1171
Location: Overflow
Matrix
Madis731 wrote:
Aren't the 64 and 32-bit variants of Intel CPUs equally priced? You can even buy a 64-bit Celeron for about $100 to test this code Wink


thx, but i need now, new ram, new processor, motherboard, video card, hdd, dvdrw, monitor, keyboard, and some rack Wink
Post 12 Dec 2005, 03:56
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
What if we hypothetically rewrite all functions. What happens to that file in general. I mean it doesn't get any smaller because the function entry addresses must remain the same - you might only get it smaller by optimizing the last function in binary for size.
What happens when your new code is more speedwise than size? You will use freed space from other function and jump or call to these Sad This makes for pipeline flush penaly and speed bump.

How would a separate DLL be possible? Do you have to change all references to these functions? Raw-linked programs will not work then Sad
Post 12 Dec 2005, 08:03
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
With the amount of space there's no way that I've found to optimize ALL the memory moves. I've tried a few methods but I either run out of space or I only speed up small sizes and medium sizes are slow or visa versa. AMD64 optimization guide was pretty much followed to the letter in the 64bit memmove.

If someone else wants to give it a try good luck the source for the function is 14posts /\ up.
Post 13 Dec 2005, 23:26
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
decard



Joined: 11 Sep 2003
Posts: 1092
Location: Poland
decard
Why you can't change addresses of functions?
Post 13 Dec 2005, 23:37
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Madis731 wrote:
Raw-linked programs will not work then Sad
However, which important raw-linked program will not work? raw-linking is not the correct way of importing a function, for that exists the import table (and LoadLibrary/GetProcAddress stuff)
Post 13 Dec 2005, 23:48
View user's profile Send private message Reply with quote
vbVeryBeginner



Joined: 15 Aug 2004
Posts: 884
Location: \\world\asia\malaysia
vbVeryBeginner
Image

sorry, not intend to
Quote:
I think we've trailed away from the point...


Last edited by vbVeryBeginner on 15 Dec 2005, 03:54; edited 1 time in total
Post 14 Dec 2005, 22:05
View user's profile Send private message Visit poster's website Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22
I think we've trailed away from the point...
Help me optimize the win64 memmove function END STATEMENT

Anyone know of an AMD *64* paper that has source code on an amd lab optimized memmove?
There's AMD provided source for an MMX memmove but thats not for 64bit architecture.
There 64bit opt guide just says "Your OS will proivde an optimized memmove blah blah blah"
Post 15 Dec 2005, 01:13
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
I think that mov is optimized...

Rather try to look for some other extremely-bad optimized function which is often used, you will get more speed that way.
Post 15 Dec 2005, 01:24
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
lilljocke



Joined: 28 Dec 2004
Posts: 34
Location: Sweden
lilljocke
Here is a tool for creating a patch to your patched ntdll file. I have tested it my self and it works finne Smile. I have not coded any size or CRC check to the patcher becouse it is can be different size between the files.


Description: If there any probelm so please let me know.
Download
Filename: Make System File Patcher.zip
Filesize: 4.25 KB
Downloaded: 135 Time(s)

Post 15 Dec 2005, 22:15
View user's profile Send private message Visit poster's website Reply with quote
Madis731



Joined: 25 Sep 2003
Posts: 2141
Location: Estonia
Madis731
Does this old source of memcpy() help you?
http://www.azillionmonkeys.com/qed/blockcopy.html

This is how results from the end of year 2003 are commented:

Paul Hsieh wrote:
Update (9/11/03): For the Athlon XP processor, using the xmm registers (SSE) leads to a dramatic performance improvement either in or out of the cache (don't ask me why/how):


...and at the very end of the article he gives you a link to AMD's memcpy(): ftp://ftp.amd.com/pub/devconn/vcc/memcpy_amd.zip

It got me thinking here - the cache pollution theme. When you bypass cache it retains the values in it but is it that neccessary at that moment. Let's say you have a 2MB cache on modern CPU. You have a GB of data to copy or move. Would it be significantly faster to copy in strides of 128Bytes bypassing cache than copying in strides of 2MB (2097152Bytes!!!).

Why I came to this idea was the harddisk problem where you have two threads running that both access disk, but from different areas. The head flips like a maniac Razz
The problem with 128bytes is that you won't get an average speed out of it when there are jumps and comparisons included. 2MB of continuous copying would be a breeze and it would favour even RDRAMs (though they are less common) and other high-speed, high-latency RAMs. You think that they are RANDOM-access-memory, but the fact is that you won't get the full speed out of them if you randomly access by only a few bytes.

Did this make sense or should I be more specific?

_________________
My updated idol Very Happy http://www.agner.org/optimize/
Post 16 Dec 2005, 08:33
View user's profile Send private message Visit poster's website Yahoo Messenger MSN Messenger Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia
vid
due to what i 've read SSE can't be safely used in Win64 anymore
Post 16 Dec 2005, 14:48
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7721
Location: Kraków, Poland
Tomasz Grysztar
Don't you mean FPU? AFAIK, the SSE should be used instead of FPU in Win64 (since FPU registers are not preserved).
Post 16 Dec 2005, 14:54
View user's profile Send private message Visit poster's website Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia
MazeGen
You're wrong, vid, I was talking about MMX and FPU, these are not saved between process switches.
Post 16 Dec 2005, 15:03
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
Why MMX/FPU are not saved anymore? If I need a REAL10 number how can I handle it without FPU?
Post 16 Dec 2005, 15:21
View user's profile Send private message Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 975
Location: Czechoslovakia
MazeGen
See this link.

Quote:

Legacy Floating-Point Support
The MMX and floating-point stack registers (MM0-MM7/ST0-ST7) are volatile. That is, these legacy floating-point stack registers do not have their state preserved across context switches.


Why? I really don't know, maybe because the operation of saving/restoring is too slow.

How? For FP operations, you have SSE, SSE2 and SSE3.
Post 16 Dec 2005, 15:48
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7721
Location: Kraków, Poland
Tomasz Grysztar
But he's right, there's no 80-bit fp operations in SSE.
Post 16 Dec 2005, 15:59
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.