CreateWindow procedure

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. :$: