CreateWindow procedure

Whats up guys? :tongue: Let's go to the business.
Open your game.exe (I'll be using QF 1873.)

Go to this offset:

00416618

You'll reach to something like:

Quote:

---

00416618 . 75 5E JNZ SHORT teste.00416678

---

Take a look at these addresses:

Quote:

---

004166AD MOV DWORD PTR DS:[70C47C],EAX
00416625 MOV DWORD PTR SS:[ESP+38],414820
0441222A 66:C705 C0004504>MOV WORD PTR DS:[44500C0],1 -> You can find what this means in the source.

---

Open notepad and save 0x0070C47C and 0x414820
NOP ALL these lines:

Spoiler:

Quote:

---

0041661A |. 6A 6F PUSH 6F ; /RsrcName = 111.
0041661C |. 57 PUSH EDI ; |hInst
0041661D |. C74424 34 0B00>MOV DWORD PTR SS:[ESP+34],0B ; |
00416625 |. C74424 38 2048>MOV DWORD PTR SS:[ESP+38],1873a_qu.00414>; |
0041662D |. 895C24 3C MOV DWORD PTR SS:[ESP+3C],EBX ; |
00416631 |. 895C24 40 MOV DWORD PTR SS:[ESP+40],EBX ; |
00416635 |. 897C24 44 MOV DWORD PTR SS:[ESP+44],EDI ; |
00416639 |. FF15 C0A25B00 CALL DWORD PTR DS:[<&USER32.LoadIconA>] ; \LoadIconA
0041663F |. 68 007F0000 PUSH 7F00 ; /RsrcName = IDC_ARROW
00416644 |. 53 PUSH EBX ; |hInst
00416645 |. 894424 48 MOV DWORD PTR SS:[ESP+48],EAX ; |
00416649 |. FF15 BCA25B00 CALL DWORD PTR DS:[<&USER32.LoadCursorA>>; \LoadCursorA
0041664F |. 6A 04 PUSH 4 ; /ObjType = BLACK_BRUSH
00416651 |. 894424 48 MOV DWORD PTR SS:[ESP+48],EAX ; |
00416655 |. FF15 24A05B00 CALL DWORD PTR DS:[<&GDI32.GetStockObjec>; \GetStockObject
0041665B |. 8B0D 28DA5E00 MOV ECX,DWORD PTR DS:[5EDA28] ; 1873a_qu.0440E29E
00416661 |. 8D5424 2C LEA EDX,DWORD PTR SS:[ESP+2C]
00416665 |. 52 PUSH EDX ; /pWndClass
00416666 |. 894424 4C MOV DWORD PTR SS:[ESP+4C],EAX ; |
0041666A |. 895C24 50 MOV DWORD PTR SS:[ESP+50],EBX ; |
0041666E |. 894C24 54 MOV DWORD PTR SS:[ESP+54],ECX ; |
00416672 |. FF15 B8A25B00 CALL DWORD PTR DS:[<&USER32.RegisterClas>; \RegisterClassA
00416678 |> A1 24115F00 MOV EAX,DWORD PTR DS:[5F1124]
0041667D |. 53 PUSH EBX
0041667E |. 57 PUSH EDI
0041667F |. 53 PUSH EBX
00416680 |. 53 PUSH EBX
00416681 |. 55 PUSH EBP
00416682 |. 56 PUSH ESI
00416683 |. 8B35 ACA25B00 MOV ESI,DWORD PTR DS:[<&USER32.CreateWin>; USER32.CreateWindowExA
00416689 |. 68 00000080 PUSH 80000000
0041668E |. 3BC3 CMP EAX,EBX
00416690 |. A1 28DA5E00 MOV EAX,DWORD PTR DS:[5EDA28]
00416695 |. 68 00000080 PUSH 80000000
0041669A |. 74 07 JE SHORT 1873a_qu.004166A3
0041669C |. 68 0800CF80 PUSH 80CF0008
004166A1 |. EB 05 JMP SHORT 1873a_qu.004166A8
004166A3 |> 68 08000090 PUSH 90000008
004166A8 |> 50 PUSH EAX
004166A9 |. 50 PUSH EAX
004166AA |. 53 PUSH EBX
004166AB |. FFD6 CALL ESI
004166AD |. A3 7CC47000 MOV DWORD PTR DS:[70C47C],EAX
004166B2 |. E8 F92D1800 CALL 1873a_qu.005994B0
004166B7 |. 8B4424 64 MOV EAX,DWORD PTR SS:[ESP+64]

---

Now, open the files and open WindowsFunctions.h
Go to line 53 and edit

wc.lpfnWndProc = (WNDPROC)0x414820;

with the second value I asked you to save.
Open Declarations.h and edit

void *WindowHandle = (void*)0x70C47C;

with the first value I aksed you to change.

Now compile, and after the JNZ make a call:
CALL window.MakeWindow
Them make a JMP: JMP 004166DD

Use CFF Explorer to add your dll to you executable.
Some things:

LPCSTR Class = "Sheen";
LPCSTR Name = "PTEmu";
wc.lpszClassName = "Sheen";
hInst = GetModuleHandleA("teste.exe"); <- teste.exe your game.exe name.

Class MUST be the same value as wc.lpszClassName. Otherwise, the window creation will fail. You can edit Name with whatever name you want to.
Features:

Mouse reaches all the screen
Window in center screen


That's all folks :lol:

OBS: Compiled in VS 2010. I'm not a PRO in C++, I just do what I can :lol:

I can see you've never programmed any procedural, or CPU native compiled language before. Your source files are empty templates and you headers full of code. XD (this should be the other way around)

Headers (the .h files) are there to provide the pre-processor with enough information to know when you've made a mistake in your main source file... but you don't have any code in the source files. :S

I have no idea why you are trying to attach to "test.exe" when your dll is first loaded into game.exe. (which may well go by any other name)

Code:

---

void _declspec(dllexport) _declspec(align(4)) _declspec(naked) _cdecl MakeWindow()

---

That is the craziest declaration I've ever seen, to the extent that I can't read it... even as a prototype. (looks like some of the C source obfuscation competition entries)

You include in-line assembler in your C++?

Code:

---

                _asm
                {
                        MOV ESI,DWORD PTR DS:[CreateWindowExA]
                        retn
                }

---

In _declspec / __cdecl ESI will be destroyed before return anyway, and so your in-line assembler is forced to break our of the high level code before it can reset the frame-set it created when it was called to avoid the corruption to this register change that that would normally be the case. So what you are doing is illegally exiting from high level code and failing to clean up the frame-set. This will corrupt the stack frame leading to a memory leak IF that function is ever called.

And aside from all that, I think that either the simple modification in Butchered, or the one presented in Gregoos tutorials (when they are up) are far more practical, simply because this is to small a function to require a DLL of it's own. It's just patching one small API, and in a very blowzy manner.

The existing functionality of the code you have removed is not completely replaced with your DLL, I think. And I suspect that existing local settings which can achieve these things and more will be lost by doing this.

With that critique aside, the potential of this would be if this where a layered window, with GDIPlus bindings that could be used to overlay the UI.

I congratulate you on a good beginning, and encourage you to persevere. But I think this project is not a practical solution just yet. I also thank you for sharing your progress with us, and hope my input can help you see where you are struggling with the conventions of non .NET style coding.

:blushing: I want to put in the dll that loop: TranslateMessage(), PostMessage(), DispatchMessage() so I have to convert that block first, because in the game, they are called first. I made the esi, because I haven't patched yet the EDIT create functions, and they, in game, are called with CALL ESI which contains the address of CreateWindowEx. Thats why I made it that way.

The align is because in my previous attempt, you said I had to ALIGN 4 my functions, then I did that way.
Whats the difference of _cdecl, _stdcall or not using them?

And about the .cpp and .h, what should I do with them?

and hInst = GetModuleHandleA("teste.exe"); is to get the HINSTANCE of game.exe to pass to CreateWindowEx function.

_declspec(naked) I think it makes the code looks more like assembly when compiled. There isn't some calls that misteriously appears in the code after I compile.

I'm almost there, until now, I have stopped here:

Quote:

---

00442400 /$ 53 PUSH EBX
00442401 |. 55 PUSH EBP
00442402 |. 56 PUSH ESI
00442403 |. 57 PUSH EDI
00442404 |. 8B7C24 14 MOV EDI,DWORD PTR SS:[ESP+14]
00442408 |. 57 PUSH EDI ; /hWnd
00442409 |. FF15 88A25B00 CALL DWORD PTR DS:[<&USER32.GetDC>] ; \GetDC
0044240F |. 8B1D B0A25B00 MOV EBX,DWORD PTR DS:[<&USER32.LoadBitma>; USER32.LoadBitmapA
00442415 |. 8BF0 MOV ESI,EAX
00442417 |. A1 B8D67000 MOV EAX,DWORD PTR DS:[70D6B8]
0044241C |. 68 5C475C00 PUSH 1873a_qu.005C475C ; /RsrcName = "IDB_LOADINGLAMP"
00442421 |. 50 PUSH EAX ; |hInst => NULL
00442422 |. FFD3 CALL EBX ; \LoadBitmapA
00442424 |. 8B2D 3CA05B00 MOV EBP,DWORD PTR DS:[<&GDI32.CreateComp>; GDI32.CreateCompatibleDC
0044242A |. 56 PUSH ESI ; /hDC
0044242B |. A3 DC4ABE01 MOV DWORD PTR DS:[1BE4ADC],EAX ; |
00442430 |. FFD5 CALL EBP ; \CreateCompatibleDC
00442432 |. 8B0D DC4ABE01 MOV ECX,DWORD PTR DS:[1BE4ADC]
00442438 |. 51 PUSH ECX ; /hObject => NULL
00442439 |. 50 PUSH EAX ; |hDC
0044243A |. A3 E04ABE01 MOV DWORD PTR DS:[1BE4AE0],EAX ; |
0044243F |. FF15 50A05B00 CALL DWORD PTR DS:[<&GDI32.SelectObject>>; \SelectObject
00442445 |. 8B15 B8D67000 MOV EDX,DWORD PTR DS:[70D6B8]
0044244B |. 68 50475C00 PUSH 1873a_qu.005C4750 ; /RsrcName = "IDB_LOADIMG"
00442450 |. 52 PUSH EDX ; |hInst => NULL
00442451 |. FFD3 CALL EBX ; \LoadBitmapA
00442453 |. 56 PUSH ESI ; /hDC
00442454 |. A3 E44ABE01 MOV DWORD PTR DS:[1BE4AE4],EAX ; |
00442459 |. FFD5 CALL EBP ; \CreateCompatibleDC
0044245B |. 8B0D E44ABE01 MOV ECX,DWORD PTR DS:[1BE4AE4]
00442461 |. 51 PUSH ECX ; /hObject => NULL
00442462 |. 50 PUSH EAX ; |hDC
00442463 |. A3 EC4ABE01 MOV DWORD PTR DS:[1BE4AEC],EAX ; |
00442468 |. FF15 50A05B00 CALL DWORD PTR DS:[<&GDI32.SelectObject>>; \SelectObject
0044246E |. 56 PUSH ESI ; /hDC
0044246F |. 57 PUSH EDI ; |hWnd
00442470 |. FF15 80A25B00 CALL DWORD PTR DS:[<&USER32.ReleaseDC>] ; \ReleaseDC
00442476 |. 5F POP EDI
00442477 |. 5E POP ESI
00442478 |. 5D POP EBP
00442479 |. B8 01000000 MOV EAX,1
0044247E |. 5B POP EBX
0044247F \. C3 RETN

---

Almost everything from CreateWindow until here is patched.

Quote:

---

Originally Posted by SheenBR

:blushing: I want to put in the dll that loop: TranslateMessage(), PostMessage(), DispatchMessage() so I have to convert that block first, because in the game, they are called first. I made the esi, because I haven't patched yet the EDIT create functions, and they, in game, are called with CALL ESI which contains the address of CreateWindowEx. Thats why I made it that way.

---

Well, TranslateMessage(), PostMessage(), DispachMessage() is all the window IO handeling, which means you are trying to re-write every mouse click and key press in the game, and every event (System Shutting down, Sleep mode started, Lid closed on laptop, Window moved, Maximised, Minimised etc)

The C++ compiler has optimised the all the calls to CreateWindowEx by storing the offset in ESI, because it is used a lot in small section of code. You save a lot of bytes in byte-code and many memory wait T-States by sticking the offset in a register and referencing that instead of the offset directly.

Quote:

---

Originally Posted by SheenBR

The align is because in my previous attempt, you said I had to ALIGN 4 my functions, then I did that way.

---

Align 4 is the default for Visual C++ and the x86 target. (either in Debug or Release builds) It is a compiler switch, because on the ia32 architecture Calls and references to addresses aligned to DWords (32-bits) is much faster. You can change the project settings to align to anything from 1 byte to 64 bytes. Only 1, 32 or 64 makes any sense in most cases. But there are a few instances where you may want to Align one function, or exported data item, differently to the rest of the project.

Quote:

---

Originally Posted by SheenBR

Whats the difference of _cdecl, _stdcall or not using them?

---

They are standard calling conventions. Microsoft uses a lot of aliases like "WinAPI" = __stdcall and "_declspec" = __cdecl. The difference? You really should look up.

Basic summery is that __stdcall is MS specific API calling convention where parameters are passed on the stack, and removed before the function returns. __cdecl is the C standard calling convention where parameters are passed on the stack and then removed after the routine has returned. So __stdcall is Microsofts' __cdecl++, if you like. Mostly it is no improvement, but it can be in instances where the routine simply POPs the parameters off the stack, so it doesn't have to PUSH them back before returning. __fastcall is the latest and greatest thing, and much more optimal. In this case parameters are passed via the general purpose registers EAX, EBX, ECX etc. until you run out of those on the CPU architecture you are using, and any more are passed via the stack and returned as per __stdcall. This is the *only* method that will work in x64 architecture with all the Win32 APIs.

More important to keep to hand a reference of these, as different calling conventions preserve, or make not guarantee of preserving different registers (ie. it's best to consider their content invalid or destroyed after returning from the CALL) under different architectures. The x86 / ia32 architecture is the one most documented, so it should be easy to find... but I can never remember them off the top of my head.

The standard Visual Studio "Empty DLL" template creates a #Define for creating DLL exports. (I know Vormav didn't use the ones that Dev-CPP created either, and I usually change what it's called)

Visual C++ creates Test.h

Code:

---

// The following ifdef block is the standard way of creating macros which make exporting
// from a DLL simpler. All files within this DLL are compiled with the TEST_EXPORTS
// symbol defined on the command line. this symbol should not be defined on any project
// that uses this DLL. This way any other project whose source files include this file see
// TEST_API functions as being imported from a DLL, wheras this DLL sees symbols
// defined with this macro as being exported.
#ifdef TEST_EXPORTS
#define TEST_API __declspec(dllexport)
#else
#define TEST_API __declspec(dllimport)
#endif

// This class is exported from the Test.dll
class TEST_API CTest {
public:
    CTest(void);
    // TODO: add your methods here.
};

extern TEST_API int nTest;

TEST_API int fnTest(void);

---

Full of OOP nastiness that will be a complete pig to integrate into our Olly Disassembly, and have no real need for anyway. (unless you are being adventurous enough to implement GDIPlus or replace the DirectX mess)

But you can keep the #define even if you are using pure C, or (as I tend to) blended C / C++ code.

So the header from a recent project, where I'm trying to strip all the stdio stuff from the exe, to make it smaller and easier to read, and possibly target it at something other than the buggy stdio that comes with CV7.1 (it just is, and I'm fairly sure they haven't replaced stdio.h with a less buggy version like the CV6 or CV8 + versions)

Code:

---

#ifndef _DLL_H_
#define _DLL_H_

#define DllImport __declspec(dllimport)
#define DllExport __declspec(dllexport)
#endif /* _DLL_H_ */

---

Then in the CPP file I can use that define like so:-

Code:

---

DllExport int __cdecl
    Cremove(const char* filename)
{
    return(remove(filename));
}

---

I've actually limited a lot of that, as I'm now using a custom .def file to gain greater control over the export names, so Cremove becomes exported, simply, as remove(). (as it is in regular stdio.h when included in-line via a .lib file) but you needn't go to that extreme.

Quote:

---

Originally Posted by SheenBR

And about the .cpp and .h, what should I do with them?

---

The .h files should only contain typedefs, #defines, enums, #include, #pragma [once] and prototypes for any functions included in the main source file.

All the actual code should be in the C, or CPP files.

Quote:

---

Originally Posted by SheenBR

and hInst = GetModuleHandleA("teste.exe"); is to get the HINSTANCE of game.exe to pass to CreateWindowEx function.

---

but it isn't getting the module handle of game.exe, it's getting the module handle of "teste.exe", or probably an error that should be handled with GetLastError.

To quote GetModuleHandle Function (Windows)

Quote:

---

Retrieves a module handle for the specified module. The module must have been loaded by the calling process.

---

The game (I believe, and in most builds) calls GetModuleHandleA(NULL); which I will quote again.

Quote:

---

If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process (.exe file).

---

I'm not convinced that that won't get the module handle of your DLL, as that will then be the current active module, you should pass the module handle of game.exe to your DLL function, or preferably the address of the Window Message (WM) handling routine it's self.

Quote:

---

Originally Posted by SheenBR

_declspec(naked) I think it makes the code looks more like assembly when compiled. There isn't some calls that misteriously appears in the code after I compile.

---

Yes, I think you are right. I suspect that the (naked) keyword is telling it not to create a stack frame and preserve registers. Which may avoid the stack growth memory leak I mentioned, but would be very dangerous in terms of the register preservation.

I guess it may be "safe" but it just doesn't look it... ... at all. :s It look "scary".:lol:

I see. I'm remaking it using only _stdcall and using in the right way the .cpp and .h. Also, I succesfully "patched" the PTREG procedure, so everything related to the ptreg (window mode settings, network settings, screen size etc) are in C++ now.

Yes, I want to remake every click event, mouse event and stuff. That way, in WM_CREATE I think I can add every thing that I want in login screen. A button, a label, etc.
That way, I could add sub servers button, so when you login, you login directly to that subserver, you wont have the "Alpha" and "Beta" subservers now.When I click to the buttom, I simply make a lstrcpyA to the IP offset and change it. Sounds pretty good, isnt it? :lol:

Sounds pretty ambitious considering how "green" you are on raw x86 compiling, without the DotNet framework "safety net" between you. :wink:

But you'll learn a lot.

I have all the registry and text file configurations mapped to a DLL, but I'm working on making XML, .ini and considering SQLite data-stores to back those settings. Right now, I'm keeping them as constants in the DLL, which may be secure, but isn't much use to anyone. :lol:

wow, that EDIT CreateWindowEx is already "patched" :P

bob, is there a better name of what I'm doing instead of saying "patched"? IDK how to express myself in this context.

and btw, I'd like to say, none of this would be possible without the help Vormav gave and keep giving me. He helped me a lot of how to make that pointers, like that:

MOV DWORD PTR DS:[offset],value
and how to Hijack the PT Calls.

I think "patch" is a reasonable term. It is usually applied to edits which can be applied to a source repository, but we all know it gets used when applying "fixes" and "updates" to binary distributions as well. "KB patches" from Automatic Update / Windows Update for example.

"Hijack" is not quite correct. That would suggest you make no alterations to the original executable at all, but only capture it's communication with the OS and underlying APIs while it's running.

Vormav suggested that International.dll was essentially doing what many hacking tools do, to "Hijack" API calls... which it is, but it's not "Hijacking" since it doesn't "inject" it's self at load time or require an external "DLL injector" but does require that the main game executable be re-written to work from it, rather than the APIs it was calling before.

I think i'm doing well, since I'm a noob in C++. ATM, I have removed from game.exe until the SetWindowLongA Call. I think I make it work till the end of the night. (its 18PM here :lol: )

Is it normal to write everything into header in C#? XD
In C++ is not >=P

For now I see this in your code:

http://img158.imageshack.us/img158/1...etmusicmd0.jpg

I will look into it again when you finish it.

Good luck with it, I am interested in anything thats window related... planning to write movie player "from inside of PT window" O__o
GO GO!

PS. Still can't find good reason to try C# ... everybody telling me that C++ if faster.

Quote:

---

Originally Posted by Vormav

Is it normal to write everything into header in C#?

---

There is no such thing as "header" in C# :ott1: (I know, it did my head in at first too.) :lol:

Quote:

---

Originally Posted by Vormav

PS. Still can't find good reason to try C# ... everybody telling me that C++ if faster.

---

Okay, I will tell you that C# is faster. (potentially)

Spoiler:

I will also say, can you find a C++ compiler that can compile a C++ program into a single file which will run flawlessly on Windows, XBox, PS3, Mobile Phones (Apple and Windows Mobile based etc.), Mac, Linux and BSD regardless of the CPU the OS is running on?

This is possible with C#. The only other possibility is Java, and that compiles to a package (modified zip file) not a true executable.

A .Net MSIL / CLI binary is a PE file. It can be run on anything with either Microsofts' DotNet Framework, or Mono installed, and will optimise the JIT code produced from the IL for whatever CPU is on the system.

So where a C++ program would either have to be optimised for MMX or SSE or SSE2 or 3DNow or Altivec or have a complex mechanism for determining these CPU extensions and switching between in-line assembler to achieve the extra boost they will get you, a C# (or any other .Net language that is build to cross-platform Native IL code) will automatically be adapted to take advantage of the features of the host system.

That's why it's "potentially" faster, because if your C++ is built for the exact target that it is run on, then it gains by not needing the JIT byte-code compiler to cache a machine specific optimised version of it... but if it's targeted at a "blended" or "generic" i386 style CPU, it will loose out massively on the many advanced features available on modern CPUs.

The problem for us is... PT can't use it, because it's already fixed to the Win32 x86 platform. Oh well.

Before .Net 3 I hated the framework, which seemed to be the cause of all of my greatest troubles on my system. I dreaded the idea that Vista was going to use .Net for the entire desktop and that GDI was becoming a wrapper for the .Net only Windows Presentation Foundation... but with .Net 3.0 + it hasn't given me so much as a hickup either on Windows or Linux, or even my wifes' iPhone since.

Shouldn't this be moved back to the parent forum until it's actually ready ?

It is ready. Take a look at my first post. All I'm doing is updating it.

I see ^_^

To be fair... it works, it's just that the source is... umm... a little unconventional? :lol: ++ :lol:

The last pastebin I saw looked much more readable. Though I'm still not sure why *I* would personally use it... it may be a good starting place for someone who wanted to try for something more.

It does mean you have a good handle on the Window and it's Device Context and WM callbacks in your C source DLL... and that's powerful in it's self.

SheenBR for version 2.0 I prose you to put all code into Window.cpp :ott1:

Quote:

---

Originally Posted by bobsobol

There is no such thing as "header" in C# :ott1: (I know, it did my head in at first too.) :lol:Okay, I will tell you that C# is faster. (potentially)[...]

---

If its like Java than I don't think that "real" commercial games written in C# will show up. Disassembled C# will give you clean C# code? Well Java and 3D simple don't like each other :) And in C# you don't have control over your memory... I don't like that.

This is a C++ project. Other languages are use for it. (I could port it to freeBASIC or Object Pascal I suppose, but I don't see the point. XD)

Spoiler:

Quote:

---

Originally Posted by Vormav

If its like Java than I don't think that "real" commercial games written in C# will show up.

---

You just said nothing will ever be written for the XBox-360, which can only run .Net applications, and not ones written in managed C++. So the only real language any of them can be written in is C#. Though XNA or Unity is fine for small projects.

I have Codemasters F1 2010 which (is a git on the PC, because it requires XBox peripherals to play but) appears to be written in a combination of C# and XNA.

Quote:

---

Originally Posted by Vormav

Disassembled C# will give you clean C# code?

---

No, it will give you MSIL byte-code mnemonic. The .Net Framework is a VM, like Java, but more optimal. And Oracles VJM has learned JIT compilation from the .Net Framework. With .Net 3.5 MS caches the optimized JIT code for your CPU at the point you install the application, then the .Net executable is just a header and kept so you can move it to another machine and it can optimise it for that one. The CPU specific code for a P4 is very different from that for an AMD x64, and both are very different from the code produced on an Intel Core CPU.

Quote:

---

Originally Posted by Vormav

Well Java and 3D simple don't like each other :)

---

Disputable.
Jirr | Download Jirr software for free at SourceForge.net

Quote:

---

Originally Posted by Vormav

And in C# you don't have control over your memory... I don't like that.

---

You have complete control over the memory of your virtual machine.

You can compile C# to managed x86, but that is as much a waste of a good resource as compiling C++ to "managed" x86 IMHO.

The positive thing about C# is that it is the most complete and professional way of creating CPU and OS independent MSIL executables. Though I have considered the possibility of creating an MSIL Assembler that can build an executable from IL op-codes. XD

Spoiler:

Quote:

---

Originally Posted by bobsobol

You just said nothing will ever be written for the XBox-360, which can only run .Net applications, and not ones written in managed C++. So the only real language any of them can be written in is C#. Though XNA or Unity is fine for small projects.

---

I see.

Quote:

---

Originally Posted by bobsobol

I have Codemasters F1 2010 which (is a git on the PC, because it requires XBox peripherals to play but) appears to be written in a combination of C# and XNA.No, it will give you MSIL byte-code mnemonic. The .Net Framework is a VM, like Java, but more optimal. And Oracles VJM has learned JIT compilation from the .Net Framework. With .Net 3.5 MS caches the optimized JIT code for your CPU at the point you install the application, then the .Net executable is just a header and kept so you can move it to another machine and it can optimise it for that one. The CPU specific code for a P4 is very different from that for an AMD x64, and both are very different from the code produced on an Intel Core CPU.

---

I usually like MS products like windows and office but I have feeling that MONO will be left behind.

Quote:

---

Originally Posted by bobsobol

Disputable.
Jirr | Download Jirr software for free at SourceForge.netYou have complete control over the memory of your virtual machine.

---

What is it? It look like some old render from 3D Studio DOS... to be fair 3D Studio release 1 XD

Quote:

---

Originally Posted by bobsobol

You can compile C# to managed x86, but that is as much a waste of a good resource as compiling C++ to "managed" x86 IMHO.

The positive thing about C# is that it is the most complete and professional way of creating CPU and OS independent MSIL executables. Though I have considered the possibility of creating an MSIL Assembler that can build an executable from IL op-codes. XD

---

Maybe I will try this language hybrid called C# when I find patch that bring back headers ;)

http://oi54.tinypic.com/2afc429.jpg

Nothing better to do ;)
I still waiting for version 2.0, maybe I don't look like that but I am quite pedantic when come to code formating, SheenBR have good composition... only if not this empty .cpp file XD

Spoiler:

Quote:

---

Originally Posted by Vormav

I usually like MS products like windows and office but I have feeling that MONO will be left behind.

---

Mono is the only .Net Framework supported on any OS or CPU that Microsoft doesn't, and they don't support anything they didn't write. Though I suspect most people develop for Mono in Visual Studio, it has already surpassed the .Net framework in terms of the number of platforms it supports, and enhanced the feasibility of the .Net Framework just as Microsoft intended when they released the Framework and MSIL specifications into the public domain. They don't want to support Mac OS and Linux and iPhones and iPods and PalmOS and ... and ... etc. But they do want their standard to be useful as a cross-platform tool, or it won't be accepted at all. Increasingly, if developers can't port their code to emerging technologies (palmtops and PDAs and smart phones, Android and iOS and so on) then they don't use that language.

Quote:

---

Originally Posted by Vormav

What is it? It look like some old render from 3D Studio DOS... to be fair 3D Studio release 1 XD

---

Did 3D Studio 1 support Shader Model 2.0 for both DirectX 9 and OpenGL and the Newton Physics engine? Full screen shaders and per-pixel lighting effects including speculative, bumpmapping and paralax shading? I don't think 3D Studio was ever made for DOS, but I don't think those real-time engines existed when it was made.

Irrlicht is a pretty awesome Open Source real time 3D rendering engine. It's APIs have been ported to many languages, including Perl, Python many variants of Basic... I'm not surprised it is available to Java now. Okay, it's not the UDK, GameBryo or Havok... but it's pretty good for free speech, change the code, do what you want with it software.

But Java can interface with WPF or DirectX if it wanted to. (hence why I didn't initially see the need for a competing cross-platform standard. I couldn't see anything .Net could do that Java or Python couldn't, but Since version 3 / 3.5 it has become more a powerful and elegant solution than either of those)

Quote:

---

Originally Posted by Vormav

Maybe I will try this language hybrid called C# when I find patch that bring back headers ;)

---

The specification for C# basically says that one of the primary reasons for creating it was that "headers are archaic nonsense that needs to be thrown out along with EBCIDIC and the slide rule." I don't agree, but I was also quite confused when they started introducing headers into Pascal and Basic... so I do remember we used to manage without them perfectly well. It just makes the compilers job that much harder, and compile times that much slower. It also confuses me, because I look to the headers to find the definitions of types and prototypes... You're supposed to "trust code-sense" for that now... Not so convinced by that, but it is do-able.

what's going on here? :lol:

The origins of your unorthodox C++ are being debated beyond the scope of the original topic. lol It's not "Off" topic, but "aside from" so, it's increasingly collapsed not to bore those uninterested in the side-topic.

Side topic = "Headers: Who needs them - and is anything that doesn't ultimately lame." :lol:

Spoiler:

Don't need headers in Assembler... there's no definition for a .ah file... but making a .asm that is #included with all your definitions and macros in it is a big help. :wink:

Assembler is definitely faster than C++... if you do it right. And therefore definitely not lame. :lol:

xDD

Well,atm, I am patching from this offset.

CPU Disasm
Address Hex dump Command
0041678D |> \3BC3 CMP EAX,EBX
Everything from the createwindow procedure till here is patched inside my C++ dll.

---------- Post added at 03:55 AM ---------- Previous post was at 03:22 AM ----------

Yes, patched! u.u

'Till here now:

CPU Disasm
Address Hex dump Command
0041684A |> \8B35 94A25B00 MOV ESI,DWORD PTR DS:[<&USER32.PeekMessa

Quote:

---

Originally Posted by bobsobol

I can see you've never programmed any procedural, or CPU native compiled language before. Your source files are empty templates and you headers full of code. XD (this should be the other way around)

Headers (the .h files) are there to provide the pre-processor with enough information to know when you've made a mistake in your main source file... but you don't have any code in the source files. :S

I have no idea why you are trying to attach to "test.exe" when your dll is first loaded into game.exe. (which may well go by any other name)

Code:

---

void _declspec(dllexport) _declspec(align(4)) _declspec(naked) _cdecl MakeWindow()

---

That is the craziest declaration I've ever seen, to the extent that I can't read it... even as a prototype. (looks like some of the C source obfuscation competition entries)

You include in-line assembler in your C++?

Code:

---

                _asm
                {
                        MOV ESI,DWORD PTR DS:[CreateWindowExA]
                        retn
                }

---

In _declspec / __cdecl ESI will be destroyed before return anyway, and so your in-line assembler is forced to break our of the high level code before it can reset the frame-set it created when it was called to avoid the corruption to this register change that that would normally be the case. So what you are doing is illegally exiting from high level code and failing to clean up the frame-set. This will corrupt the stack frame leading to a memory leak IF that function is ever called.

And aside from all that, I think that either the simple modification in Butchered, or the one presented in Gregoos tutorials (when they are up) are far more practical, simply because this is to small a function to require a DLL of it's own. It's just patching one small API, and in a very blowzy manner.

The existing functionality of the code you have removed is not completely replaced with your DLL, I think. And I suspect that existing local settings which can achieve these things and more will be lost by doing this.

With that critique aside, the potential of this would be if this where a layered window, with GDIPlus bindings that could be used to overlay the UI.

I congratulate you on a good beginning, and encourage you to persevere. But I think this project is not a practical solution just yet. I also thank you for sharing your progress with us, and hope my input can help you see where you are struggling with the conventions of non .NET style coding.

---

I agree with a lot of what you said, but including inline ASM in your C++ is perfectly acceptable. Most of my DLL's for GunZ have huge chunks of assembly in them just to avoid having to deal with editing the runnable for some things. Also helps if you want to toggle the changes on/off on the fly from some sort of case or switch or key press.

Yes yes!

Trouble is I tend to write the DLL in assembler, not C. Or in freeBasic and assembler (in-line or otherwise), and I am constantly asked "What is the point of using a DLL when you just write assembler in it anyway? Why not just put the assembler in a new section in the main game file?" (the tradition in PT developments)

Spoiler:

The answer (of course) is that it's easier to test and develop the DLL externally. Pass it all sorts of rubbish and prove that it's resilient; expand, rewrite from scratch or even replace it with something that does something completely different but hooks into the same area. (GM commands or packet checksums for example)

I just get ragged for using Asm (and fb) because people want to see C# of VB.net DLLs (face-palm) and Asm in the original PE only.

As far as I'm aware .Net languages don't make DLLs that don't need the host application to be .Net Framework applications, and whatever high level code you write, the Assembler is still something you really need to know. (one way or another) :wink:

In that snipped, I was concerned about the stack frames that the C routine would normally make on call, and the inline assembler is avoiding automatic clean-up of. But further down the discussion I decided Sheen is probably right, and the fact that he declared the procedure "naked" should mean it isn't a problem.

I got a "PasteBin" of his "in progress" reworking, and it's much more cleaned up and readable, and it doesn't "scare me" half as much.:lol:

He also has some ideas on "expansion" which would make the effort of breaking out to a DLL more worthwhile. So we all sit expectantly in waiting.

Sounds nice. I've never actually gotten too deep into PT.

I just lurk pretty much all of RZ and saw a logical conversation on coding so I had to stop in. My knowledge is I wouldn't say high, but I know a fair bit. I'm set in my roots now I've been at it for so long. Mostly for GunZ, but I've hopped around for some battle.net games as well making C++/Delphi DLL's

Don't know much about GunZ, though we do interact with the MU and Cabal devs as some of the techniques apply across those games too. (similar code style and original dev practice)

Spoiler:

If you follow battle.net maybe I should ask you if you know a good way to disable / change the checksum that locks up changes to the interface.mpq\Interface\GlueXML\AccountLogin.xml or whatever which means you get official Blizzard downtime notifications, and not ones for your own server. XD The RZ WoW section seems pretty quiet. :$: