(May 29th, 2016, 11:07)Bogus Wrote:(May 29th, 2016, 10:28)Seravy Wrote: I'm assuming you moved the location of, or otherwise interfered with the far calls used. If so, did you update the relocation tables? (if it's in the ovr part of the file then it needs to be done to the relocation table of the segment instead of the global one.)
Also, did you take the addresses for the calls from the exe file or the disassembler? The latter shows already relocated addresses which cannot be used in the source.
nope, i didnt move the calls and i took the calls from the exe, not the db. i did remove 2 of the calls, but i tested the exe after removing the calls and changing the adress of the strings, and it worked. it displayed the strings and icons in the normal locations but without the descriptions, as intended. i just jumped over these calls for the test, but to add the code for my changes i needed the space. maybe i just cant have any other code where a call would normally happen?
I assume by deleting you mean replacing by NOP (90h). Those, if a relocation entry points at them, tend to get turned into something that does not cause an immediate crash but might corrupt data in memory. If you disassemble the file after doing that, it'll show something like "add es:[bx+si],70h" in red. There is no crash because it's a valid instruction, but it DOES change data in the memory somewhere at random so it shouldn't be left that way.
You either must leave every far call on the exact same address still functional, or skip them through a jump (only the last two bytes of the 5 byte far call instruction get relocated so replacing 9A,xx,xx,xx,xx with EB,03,xx,xx,xx is safe), or find the relocation table entry referring to that far call and move it to point to the new position of the call. It's also possible to remove or add them if you remove or add into/from the relocation table but in this case you also need to update their size entry in the stubs.
The relocation table itself is located at the end of the segment (only for ovr segments!) and is hidden in the disassembler (you need to find it with a hex editor), and contains 2 bytes per entry which is the offset within the segment (remember the last 2 bytes of the far call is being relocated).
Example : there is a far call at ovr114:0378h. You make changes to the code and it ends up at ovr114:0445h (you find this out by disassembling the file again after the changes, the far call will be red and code where it originally was will be randomly messed up).
First you calculate 0378h+3=037Bh. then you find 7B 03 at the end of the segment in the hex editor. You replace that by 48 04.
Then disassemble again and if it worked the far call will not properly show up and you can click on it to enter the called procedure as usual.