Beta Technical Demonstration - Translation without Hexing the EXE

Answers, in order:-
Q: The INI file is fictional?
A: Yes.

Q: It would slow the game down?
A: Those things? Not much.

Q: I already have in my DLL written in pascal, so to me it wouldn't make a big difference.
A: It might... because it would support using different fonts and different font styles in different places without making any modification to your executable. So Character name could use one font, Tribe another and Class another... not to mention Speech bubbles, Tooltips, Quests and Chat window.

Q: TextOut API, gets the X,Y and Z(?)
A: No, TextOut() only takes X and Y values, however it passes it's work on to DrawText(), which also allows for Alignment and wrapping to fit within a RECT structure. If I take over TextOut() API functions and implement different alignment and RECT structures, based upon the strings location in memory and offset from the values presented in by the main game.exe, we can leverage a lot more control over text placement as well as colour and style, at very little cost. (Remember, TextOut() system API works stuff out and then calls DrawText() "downstream" anyway, so we just do that our self and gain more control)

\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

New libraries! I finally got my head around the stack issues... address the stack indirectly and don't mess with the frames. XD

--- EDIT ---
!!! Warning !!!
This upload has a bad build of the Release library, I pushed it out too quick with too little testing.

If you already have this download, patch the IntStr[Release].dll with the one from my next post.

If not get the latest version from my first post in this thread, which is kept up-to-date.
---/EDIT ---
MegaUpload
DepositFiles
Hotfile
zShare
Uploading
or
All these links thanks to Multiupload.
Virus Total analysis of this file with many Anti-Virus. (in case anyone is concerned)

Place these in your game client folder. Please submit any .lng files based on the provided executable (this version now has the "rain" patch), or another based on KPT 1977 only... offsets will be meaningless to others if not, and that is not very "sharing". (then again, if you want us to do some work our selves, I guess that's a good way to go)

Additionally, please run the "SetLogging" script at least once. You can now execute this any time you want to enable the logging of captured strings (makes the game really slow, but is the best way to find offsets) or disable it, returning the game to normal running speed. (mostly)

I've not changed the format of the .lng file so far, despite the new strings with can be captured... but I have changed the log format... this is now very easy to import into a spreadsheet as a CSV (ignore the first two lines) and sort by address / string / api or remove duplicate lines all automated by the power of your spreadsheet program. I hope this makes things easier for people to find.

Enjoy, and please report back your findings... I'm now going to work on colours and fonts and positioning and things.

Thanks bob. I'll try this.

I think I have a problem, the cmd file, when I open it, it just close in the same time...

The problem I'm having is that the new Release version (non-logging) is not patching any strings. :s Odd.

--- EDIT ---
Oh... I see! It's a misplaced meta-directive in the source that's skipping an "Else" in the non-debugging build option. IDK why it compiled without error like that. :s

Please use attached alternate InStr[Release].dll instead. (If you didn't get the update in my last post, then get it directly from OP, which I've updated to include this fixed [Release] library.)
---/EDIT ---

The script just deletes IntStr.dll and asks if you want logging enabled or disabled, then copies either IntStr[Logging].dll or IntStr[Release].dll to IntStr.dll depending on your choice.

my game.exe is crashing in the select char screen bob...

*When I'm using the IntStr to debug, my game crashes in the char screen.*


Well, when I use the older version, everything goes fine, but with the new version, it always crashes in the select char screen.


Resuming, I cant use the new version. :(

I have had intermitant crashing even with the old version... fatal exception usually after connecting to the server, and before character selection appears.

Still happens now... but not all the time, and exactly which API causes it is different every time I run it under the Debugger... wait half an hour and it stops happening.

So I presume it's to do with memory fragmentation, the same as the server crash after 20hrs or so, and also presume that it will go away when the whole lot is ported to Visual C++.

I can't track down what it is, because there is no guarantee that it will even happen when I'm tracing. Sometimes it does, sometimes it doesn't. *shrugs*

If the problem is persistent, and consistent on your setup, perhaps you can figure out where it is happening. As I say, for me, it happens, but at different points in the code each time it happens, and it doesn't usually happen, just sometimes it does.

When it does it happens and happens and happens and I think I've changed something and I go back to older builds and it still happens and I go away, play a different game or run a different game executable or watch some TV and come back and it's fixed it's self, without explanation.

I don't know how to debug a problem that presents with a different cause but the same effect every time it happens, and doesn't always happen even when given exactly the same circumstances. I've stack traced, and found it reading or writing to memory that hasn't been allocated in aton in WS2_32 and in wsprintf from kernel32 (not my one) and in game.exe and in many other APIs, all using different non-existent memory, and never the same one twice.

I think I've added correctly, because the older version works perfectly... Are you sure this isnt to do with the dll?

Well... I really can't say, because the original version I posted did it to me, and this new version doesn't do it any worse.

It happened then, and it happens now. And like a watched pot, it only ever happens when I'm not looking at it. XD

Well, I'll try it again, and again....

If it isnt ask too much, could you share the sources of the first version?
I'd like to translate it to delphi.

---------- Post added at 07:08 PM ---------- Previous post was at 06:57 PM ----------

Here what is happening

http://img809.imageshack.us/img809/7187/crashe.jpg

Oh, the high level bit?
IntStr.bas
CharConst.bi
IntStr.bi is a one-liner so far

Code:

---

#Include "windows.bi"

---

IntStr.rc
The freeBasic project file for management of the project with fbEdit is:-

Code:

---

[Project]
Version=3
Description=Internationalisation for Priston Tale Strings
Api=fb (FreeBASIC)
Grouping=1
AddMainFiles=1
AddModuleFiles=1
ResExport=
CompileIfNewer=0
IncVersion=1
RunCmd=0
[Make]
Module=Module Build,fbc
Recompile=2
Current=1
1=Windows dll,fbc -s gui -dll -export
2=Static lib,fbc -lib
Output=
Run=
Delete=*.obj; *.a
[TabOrder]
TabOrder=1,2,3,4
[File]
1=IntStr.bas
2=IntStr.rc
3=Inc\IntStr.bi
4=Inc\charconst.bi
[BreakPoint]
1=
3=
4=
[FileInfo]
1=0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
2=0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
3=0,0,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
4=0,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

---

--- EDIT ---
In English "This application has encountered a problem and was shut down to protect your system." then "Would you like to report the problem to Microsoft?" who will completely ignore it. XD

Sounds about right, I have run-time debugging on and error reporting off, so I know that it performs an illegal memory access from different instructions and different locations in the code, upon different illegal memory addresses. All different every time, but always at about the same place. (connecting to server and getting character details for an account)

Almost as if it's getting something from the server at login which is beyond it's capability to deal with properly.

Porting to Pascal may be as effective as porting to C++, as I suspect the random nature of it is down to the memory management in the runtime library for freeBasic, which is solid on it's own, but is being mixed with VCs runtimes... they may not "play nice". I've seen VC get equally shirty about DLLs compiled with GCC, and then you compile the main exe with GCC and everything is fine and dandy... Oh! And even more so with a VC executable using a Borland C++ Builder DLL.

Thanks bob. And, just for logging, the crash is also happening with the new client and new dlls you've posted.

I dont understand the sources, is it VB6?

@edit

The exception, in the first SS I showed, occurs in this offset:
168B71AA

That offset is nonsensical, that's why it's illegal.

No it's not VB6, I believe I stated quite clearly that it is freeBASIC, which builds to GAS source against MSVCRT.dll which it assembles with GNU GCC from the MinGW (hence the MSVCRT dependence) and links with GoLink to the fbrt.bin library. :wink:

freeBASIC is like QBasic only with more ability to ObjectOrient than VB6, and less enforcement on OOp than VB.net. And you can in-line assemble like BlitzBasic.

It's similar to the way ObjectPascal is a bit like Delphi and a bit like GNU Pascal and also kinda like neither of them. :lol:

--- EDIT ---

http://b.imagehost.org/0432/Image1.jpg
http://d.imagehost.org/0873/Image2.jpg
http://b.imagehost.org/0771/Image3.jpg

All taken with logging enabled.
To evidence this logging, this is a fragment taken during Character Selection:-

Code:

---

wsprintf(), 6091092, "%d", "/* Not Replaced */"
TextOutA(), 1571880, "91", "/* Not Replaced */"
TextOutA(), 53925752, "noobie", "/* Not Replaced */"
wsprintf(), 6194412, "템스크론", "Tempeskron"
wsprintf(), 6053916, "%s", "/* Not Replaced */"
TextOutA(), 1571880, "Tempeskron", "/* Not Replaced */"
wsprintf(), 6067616, "파이터", "Fighter"
wsprintf(), 6053916, "%s", "/* Not Replaced */"
TextOutA(), 1571880, "Fighter", "/* Not Replaced */"

---

And, to be clear, I don't doubt the difficulty you are experiencing, and have (intermittently) experienced it my self. But there isn't a lot I can do with it as I can't reliably reproduce this issue at will to discern what is causing it... and even when I do "catch" it in the debugger, it always seems to originate from a different source... all the details are changed from the last time I saw it.

If the address you mention is consistent, I'd love to know what code thinks there is something at that address, or if (as is indeed possible) there actually is some allocation to this process at that location on your system... because there is certainly nothing at so high an address when ever I run the game.

As to reading the source, it's very similar in dialect to classic ASP, but if particular points are confusing to you I'll happily attempt a translation of sections. It's unfortunate that Visual C++ is the most widely known and available development platform on Windows, because I could easily port this code to BCB using the VCL (which it shares with Delphi) but the conversion is much harder when restricted to ATL and MFC frameworks. Even I have to admit that the .Net framework would be preferable in this instance, but MSIL is no use to PT. XD

Bob, even with this executable of yours, I cant run the game. With this exe, I cant even see the login page, the game just disappear after the last loading bmp fades away...


And no, the crash offset changes all the time...

I could select the char to patch the Morion and Mage, but the game is still crashing.
I think I could try to use this new version only to patch the Tribe & Class stuff...

---------- Post added at 11:21 PM ---------- Previous post was at 11:05 PM ----------

This is the third time I got this error. And, this offset is constant.

http://img88.imageshack.us/img88/8868/crashls.jpg

---------- Post added at 11:23 PM ---------- Previous post was at 11:21 PM ----------

http://img560.imageshack.us/img560/1385/crashq.jpg

---------- Post added at 11:26 PM ---------- Previous post was at 11:23 PM ----------

In the two times the game crashed, I debuuged with C++ and, it showed me this:

14059081 mov al,[C4981528] - First Time
133C1D2A jmp C813:F73F2804 - Second Time

It appears to change, but this, is constant:(no clue of what it means)

http://img227.imageshack.us/img227/7528/33214173.jpg

---------- Post added at 11:32 PM ---------- Previous post was at 11:26 PM ----------

BOB, I JUST CANT BELIVE.

I had one char called ¹Ba¹

I already had 5 chars, and I was lazy to delet one, then I created anohter account.

BINGO!

Your dll appears not to support special characters!!! Its working now!
Well, after all these annoying messages, I have another feedback for you!
=D

Well, it's clear that you are running some form of XP, while I'm running in Vista x64.

For me, the issue is no different with either the new (rain enabled) translated exe, or the old one based on Butchered2b. And when one of them is playing up, the other does too.

It would be nice to get a feel from other people... maybe there is more of a problem on different OS, or maybe it's literally a memory thing. I have 3Gb installed, and obviously an x64 OS manages memory very differently for an x86 application than an x86 application, because it's creating a virtual 32-bit address space for that app to run in.

I usually find opening a very, very large text file, or playing back a video does... "something" (IDK what) that forces the OS to clean up and make it work, but so long as I keep trying to play PT, it will keep crashing, and always has. As I say, I put it down to the RTL for freeBASIC (or GCC, which ever way you want to look at it) not getting along with the RTL in VC. So it acts like "garbage collection" doesn't happen at the right time.

Of course the two compilers have a very different approach to memory management and garbage collection. But VC 7 has quite a different approach to VC 6, let alone going from null terminated strings to Basic strings in an array dynamically allocated on the heap. C programmers find this method very messy, but it's a lot quicker than messing about with mallocs all the time, and doesn't hit the OS so hard... at least not when you are doing it as often as this program does.

From a C / Assembler perspective, I would be looking to get an idea of how much memory to allocate before I start, and then malloc it all at once. The ATL and MFC just don't care about CPU usage and hitting the OS with complex and time costly operations and will malloc every time you instantiate a new object. So linked lists (which is the best C++ approach to a dynamic array) will be slow. The VCL works with the Heap the same as Basic and Pascal... because VCL was written in Pascal and only linked to C++ in BCB. And I believe the MSIL VM performs some kind of ranged allocation, dynamically mallocing bits of memory which it uses like Basic or Pascal allocate from a memory heap, but I've not seen clear documentation. (Maybe the Mono guys know, but I don't)

I've read that freeBASIC actually does call mallocs for new heap space, and that they worked hard to achieve good performance with this method. I've also heard that ObjectPascal uses malloc much more than traditional Pascal, and this leads to more stable and compliant LCL implementations than their equivalent VCL ones, and that's largely what the JCL did for Delphi and BCB too.

In any case... my options for ensuring it goes away completely seem (to me) to clearly be that I write either in pure Assembler (taking everything into my own control) or in Visual C++, so that it's using the same system as PT was written with.

My current (very incomplete) implementation is working on the assumption that an ATL string list object should be the way I should allocate the memory dynamically. But maybe some VC Guru out there knows better. If I went for pure assembler, I would run a two pass system, work out the total space requirement for every string in the .lng file and malloc that, then read the file again and fill in the memory allocated, and that method could be implemented in C / C++ too, but that's a waste of a high level programming language... surely? XD

Seriously though, if anyone has any better ideas on how to manage this issue, in any language / compiler / assembler I'm open to ideas. And your experience with this "bug", the frequency with which it occurs and the type of system you are running would all be good information to know.

I'll say again, freeBASIC just let me "throw it together" quickly for prototyping, Assembler simply let me ensure that what comes out of my APIs is exactly the same as what comes out of the regular OS ones, in terms of registers and stack state and so on. (It doesn't ensure that memory doesn't get fragmented to hell and back, or that I'm not going to allocate somewhere that game.exe thinks it has a right too... which it does, whether it's actually expressed that to the OS or not... we all know it's not very friendly XD)

Ultimately, I need a smaller RTL than the freeBASIC one, and I need to be able to write in a single high level language that everyone can use (which pretty much comes back to C++, and counts out using the VCL in Borland C++ Builder, which at it's minimum is bigger than the freeBASIC RTL anyway and isn't freely available) preferably using either the MFC, ATL, STL or pure MSVCRT.dll (did I miss any?) Which leaves MinGW GCC, or Visual C++... or derivatives like Microsoft C++ with Code::Blocks or MinGW with Code::Blocks or Bloodshed DevC++. Also note, I assume I'd probably better not go down the QT or GTK route with either base compiler for much the same reason as avoiding VCL, and I think I'd gain less from those frameworks than VCL as VCL isn't as focused on the "Visual" part of "Visual Component Library" as GTK and QT are on their widget systems. (I think?)

But that still leaves a lot of room for different implementations within those frameworks.

--- EDIT ---

Quote:

---

Originally Posted by lelejau

BOB, I JUST CANT BELIVE.

I had one char called ¹Ba¹

I already had 5 chars, and I was lazy to delet one, then I created anohter account.

BINGO!

Your dll appears not to support special characters!!! Its working now!
Well, after all these annoying messages, I have another feedback for you!
=D

---

Well... Erm. Most of the sql.dll and clan.dll don't support userID, password or character names with characters outside the range a-z A-Z and 0-9... because that's a requirement of the indexing in the SQL. I can't put a space, tab, shriek, apostrophe or anything else like that in any of those fields... and the game client won't let you type them either... so that's hardly surprising. XD

bobsobol, TBH I cant read all this book you've written =P

But, if you are trying to migrate from freeBasic to other language, I'd suggest Delphi.
You can use in-line assembly, and is very easy to create dlls with it.
My game stopped crashing right now, and I patched all the Tribe & Class already. If I find another bug I'll let you know.
But, once again, it would be nice if you implement some encryption in the *.lng file.

And, what are you testing/fixing/adding in the IntStr.dll ATM?
I posted something about patching the strings and also its alignment, as TextOut has two arguments: X and Y. I know, I worked with it in a hook in delphi, and I was able to move the text.

And what about that SS in ur first post? Some custom program to read the debug text file? :P

Another language that people don't have to PAY to install, that's smaller than freeBASIC... Delphi is bigger (because of VCL) and I don't know of a "free beer" version of it. :ott1:

ini file handling, colours, alignment, fonts etc.

It's not a custom program at all. It's just my Office productivity suite. Bog standard Open Office. (Isn't that what everyone uses these days? I mean, let's face it, MS Office only advantage ever was that it was cheaper than Lotus, Claris or Corals offerings... OOo is free, both as in "free speech" and "free beer", and since Office XP MS Office has really gone down hill IMHO.)