Does not launch
posted on May 24th, 2008, 7:56 am
posted on May 24th, 2008, 8:08 am
have you tried to reinstall it ? I hope so but if not that is about all the help I have 
OvermindDL2
posted on May 24th, 2008, 8:40 am
posted on May 24th, 2008, 12:03 pm
OvermindDL2
posted on May 29th, 2008, 2:32 am
Reinstalled normal A2 as well, patch 1, 1.1, and your 1.2.5 patch, none work, just shows the little splash image, then it disappears as well as the process. Don't suppose someone could compare their pre-patched (version 1.0, straight install from CD) Armada2.exe file with mine to make sure mine is not corrupted or something, here are some hashes you can compare with, pick whichever you want, I know it worked at one time (obviously...):
CRC: 65236FCA
MD5: D4884BA6B5994B6E6BF1E49A9224785C
SHA-512: C15EDFE0B5DF142B8C57E3530C40EBE3D0D5FEA4CC91FAB525B668702F245B972BE01A02ECAB678D43E2CB2512CAB2C1122DEB65DEFBEC3089ECAEACFE28941D
Whirlpool: 6DB6D422BB381E2DC32EDB5F16F886753881CC13A3F8938D27DAD65D095E98B96734A19C8B1641A4310B8EC40376FA822EC54999651589F52F5E5E73BD06002A[br]Posted on: May 25, 2008, 04:25:17 AM
Few days later, hence the new post, did some debugging on normal A2 with your latest 1.2.5 patch.
First test in the debugger:
Program Start. Reference: 0059E800
Hit two function calls, did not trace into them. Reference: 0059E813 and 0059E829
Right after the second call a pointer to an embedded string "bugs@fleetops.net is stored into the register EAX. Two more function calls occur (had a single LEA between them), did not trace into them. Reference: 0059E838 and 0059E841
Then another pointer to an embedded string "Armada 2 bug report" is stored in the register EDX (and a few more regs are filled with other data) and another call occurs. Right afer another call occurs, this call causing the splash screen to pop up for about one second then disappear, seems the return value of the function is stored in EAX, which is zero (0) on my test. Reference: 0059E850 and 0059E856
The next instruction sets EAX to zero, pops the stack a few times, puts a few other things in registers and calls another function, did not trace into. Reference: 0059E876
A return instruction is then called which jumps, oddly enough, down past the end of this function (3 instructions, this is probably the main routine with the compiler-baked functions). Reference: 0059E87B, jumps to 0059E883
It 'returned' to obviously very invalid data, thus the exception I read earlier and the program basically segfaulting. Reference: Crash occurs on 0059E888
Here is the relevant assembler of what appears to be the main function:
On doing the next run through I go into the 0059E856 call (the one that spawned the splash screen) to try to further see if I can find anything that you can match to source code to help figure out what is up (would probably be easier if you just wanted to remote debug into it though
).
Lots of little things being done, lots of function calls, pass a function that passes the pointer to a string "Armada.Execute" pretty early to help you get your bearings in the source, then realized that I was debugging into another loader app and not A2 (what is with the loader apps?) due to the Kernal32.OpenProcess call. I then decide to run Armada2.Execute for obvious reasons... Ignore the above I guess...
So, now running Armada2.Execute:
Wow, ugly freakin code, and a few exceptions being thrown even before the main loop is called thanks to some loaded dll's.
Once I got past those it seems the main app starts about at 00665E66.
The app installs a low-level structured exception handler to catch all uncaught exceptions, always a good thing (which your loader does not ever do I notice), ugly code, but well worth it.
Runs through some more of the standard Pre-WinMain crap it looks like.
It then calls some function deep within ntdll which then calls a function in non-readable memory (that is a new one on me...) thus even telling it to skip it does not work... how fun. Seems to be in ntdll.KiFastSystemCallRet, probably an exception handler, past the stuff I want...
Think I found the program's main function at 0046F720, so starting at this point now (this is before the non-readable error as stated on the previous line):
It first outputs a standard debug string of "NDEBUG defined.n".
It then creates then shows a window of Class type "Armada2Splash" (using my powers of deduction, I would have to say that this is the splash screen
). It then sleeps for 300ms for whatever reason (15ms should be fine to ensure a windows creation, or 35ms if on a 9x system, 300ms is way overkill, but whatever).
A few calls after that the program dies again, starting to trace into functions before that now:
This first one I follow seems to create the logging functionality by getting the time information, creating a log file (seems to have support for datestamped log files too, which is does not use for whatever reason), and so forth. This function works and returns fine though it seems.
Next it oddly pushes a function pointer on the stack and calls another function, somewhere in this one is where the crash occurs, so tracing into it now:
In this function the first thing it does is set the low-level exception handler to an internal function that seems like it may be backed into this function itself, with a big ol' switch statement/table (and by big I mean big, it is FB in size).
It then calls a function pointer (looks like it might be the one that was passed on the stack, but did not really check close for sure). Somewhere in this function is where it crashes, so tracing into this one now, seems this function starts on: 0046F810
The first call in it is where the crash occurs, now tracing into it, this function starts on: 0047D5B0
Seems to set some low-level keyboard hooks (very odd I must say... usually will not work on non-admin accounts, but it looks like it has a fallback for that, so no big worry, but why use an llhook at all then?). No problems to here though.
It then does things like set its AI and Missions directory to the PATH environment var (why? any good game filesystem will not need nor use that...). However this is where things seem to go wrong, let me elaborate:
It is effectively calling sprintf like this in C code:
As you can see, by my guess it seems that my system environment path of length 1721 characters is probably overflowing the buffer (which I bet they naively put at 1024 >.<; ). I am now going to test this by launching a2 through a command prompt while cutting my path to a normal couple hundred chars (just enough for windows to function well for A2 for certain). If it runs this is the problem, if not this problem still needs to be fixed regardless as it is a pretty bad bug, static buffers for external data, horrible horrible HORRIBLE mix, bad bad A2 programmers...
...
Now I test...
...
AND IT WORKS, THANK GOD.
Aren't you glad to have an external programmer/debugger sometimes.
Either way, I found a work-around, I'll just create a batch file to pre-set my PATH envar to something good for my system, you should have your patch fix that little bug in the next version because that is a pretty freaking huge bug that nothing else seems to have, probably because 'most' programmers learned long ago the horrors of static buffers with external data.
So yes, I gave you a detailed problem, the debugging path I went, and the fix, you have no excuse to fix; heck, if you want I could manually create the assembly in the executable to do it and have the function jump to that and back to fix the bug, I have done it in other commercial apps to fix bugs that are no longer being patched so I am no stranger to it, but as you are making newer 'unofficial' patches, this is something you really need to fix.
If you need help, email me at my username (OvermindDL1) at the normal gmail address.
I still cannot believe it was something as simple as a buffer overflow, some programmers really are lazy, wonder who originally wrote that function, guh...[br]Posted on: May 29, 2008, 02:33:50 AM
Also, I still cannot log into my OvermindDL1 account, still with the same above error, do not suppose you could fix that too, should be a simple DB edit (I've messed with the bridge before that you are using and encountered that bug, thought it was fixed long ago though, it is caused by changing your email address in your profile...).[br]Posted on: May 29, 2008, 02:35:44 AM
Also, if you are really cheap (and I really do *not* recommend this, but if you are going to do it, at least do it right), you could just have your loader set the envar PATH to "%WINDIR%system32" and it should work in 'most' circumstances, but maybe only do it if you detected the path being too long in the first place, say more then 500 chars to allow for the max path of 256 for the each of the passed in A2 directory strings and a little for the format string. Although this would work for anyone who does not have 'too' unusual of a setup (mine may be unusual, like my boot drive being F and so forth, but it is not *that* unusual for that to not work), but it would not always work, and it would still be best to do the real fix I documented above.[br]Posted on: May 29, 2008, 02:53:21 AM
Yes yes, another thing, sorry...
I see resolutions like 1280x960, but I do not see 1280x1024, is there some file I need to change or something?
CRC: 65236FCA
MD5: D4884BA6B5994B6E6BF1E49A9224785C
SHA-512: C15EDFE0B5DF142B8C57E3530C40EBE3D0D5FEA4CC91FAB525B668702F245B972BE01A02ECAB678D43E2CB2512CAB2C1122DEB65DEFBEC3089ECAEACFE28941D
Whirlpool: 6DB6D422BB381E2DC32EDB5F16F886753881CC13A3F8938D27DAD65D095E98B96734A19C8B1641A4310B8EC40376FA822EC54999651589F52F5E5E73BD06002A[br]Posted on: May 25, 2008, 04:25:17 AM
Few days later, hence the new post, did some debugging on normal A2 with your latest 1.2.5 patch.
First test in the debugger:
Program Start. Reference: 0059E800
Hit two function calls, did not trace into them. Reference: 0059E813 and 0059E829
Right after the second call a pointer to an embedded string "bugs@fleetops.net is stored into the register EAX. Two more function calls occur (had a single LEA between them), did not trace into them. Reference: 0059E838 and 0059E841
Then another pointer to an embedded string "Armada 2 bug report" is stored in the register EDX (and a few more regs are filled with other data) and another call occurs. Right afer another call occurs, this call causing the splash screen to pop up for about one second then disappear, seems the return value of the function is stored in EAX, which is zero (0) on my test. Reference: 0059E850 and 0059E856
The next instruction sets EAX to zero, pops the stack a few times, puts a few other things in registers and calls another function, did not trace into. Reference: 0059E876
A return instruction is then called which jumps, oddly enough, down past the end of this function (3 instructions, this is probably the main routine with the compiler-baked functions). Reference: 0059E87B, jumps to 0059E883
It 'returned' to obviously very invalid data, thus the exception I read earlier and the program basically segfaulting. Reference: Crash occurs on 0059E888
Here is the relevant assembler of what appears to be the main function:
- Code: Select all
0059E800 >/$ 55 PUSH EBP
0059E801 |. 8BEC MOV EBP,ESP
0059E803 |. 83C4 E8 ADD ESP,-18
0059E806 |. 33C0 XOR EAX,EAX
0059E808 |. 8945 E8 MOV DWORD PTR SS:[EBP-18],EAX
0059E80B |. 8945 EC MOV DWORD PTR SS:[EBP-14],EAX
0059E80E |. B8 48C25900 MOV EAX,Armada2.0059C248
0059E813 |. E8 4891E6FF CALL Armada2.00407960
0059E818 |. 33C0 XOR EAX,EAX
0059E81A |. 55 PUSH EBP
0059E81B |. 68 7CE85900 PUSH Armada2.0059E87C
0059E820 |. 64:FF30 PUSH DWORD PTR FS:[EAX]
0059E823 |. 64:8920 MOV DWORD PTR FS:[EAX],ESP
0059E826 |. 8D45 EC LEA EAX,DWORD PTR SS:[EBP-14]
0059E829 |. E8 EEA1E9FF CALL Armada2.00438A1C
0059E82E |. 8B45 EC MOV EAX,DWORD PTR SS:[EBP-14]
0059E831 |. BA 90E85900 MOV EDX,Armada2.0059E890 ; ASCII "bugs@fleetops.net"
0059E836 |. 8B08 MOV ECX,DWORD PTR DS:[EAX]
0059E838 |. FF91 D4000000 CALL DWORD PTR DS:[ECX+D4]
0059E83E |. 8D45 E8 LEA EAX,DWORD PTR SS:[EBP-18]
0059E841 |. E8 D6A1E9FF CALL Armada2.00438A1C
0059E846 |. 8B45 E8 MOV EAX,DWORD PTR SS:[EBP-18]
0059E849 |. BA ACE85900 MOV EDX,Armada2.0059E8AC ; ASCII "Armada 2 bug report"
0059E84E |. 8B08 MOV ECX,DWORD PTR DS:[EAX]
0059E850 |. FF91 AC020000 CALL DWORD PTR DS:[ECX+2AC]
0059E856 |. E8 ADD7FFFF CALL Armada2.0059C008
0059E85B |. 33C0 XOR EAX,EAX
0059E85D |. 5A POP EDX
0059E85E |. 59 POP ECX
0059E85F |. 59 POP ECX
0059E860 |. 64:8910 MOV DWORD PTR FS:[EAX],EDX
0059E863 |. 68 83E85900 PUSH Armada2.0059E883
0059E868 |> 8D45 E8 LEA EAX,DWORD PTR SS:[EBP-18]
0059E86B |. 8B15 A4BA4200 MOV EDX,DWORD PTR DS:[42BAA4] ; Armada2.0042BAA8
0059E871 |. B9 02000000 MOV ECX,2
0059E876 |. E8 F177E6FF CALL Armada2.0040606C
0059E87B . C3 RETN
0059E87C .-E9 D361E6FF JMP Armada2.00404A54
0059E881 .^EB E5 JMP SHORT Armada2.0059E868
0059E883 E8 DB E8
0059E884 74 DB 74 ; CHAR 't'
0059E885 68 DB 68 ; CHAR 'h'
0059E886 E6 DB E6
0059E887 FF DB FF
0059E888 . FFFFFFFF DD FFFFFFFF
On doing the next run through I go into the 0059E856 call (the one that spawned the splash screen) to try to further see if I can find anything that you can match to source code to help figure out what is up (would probably be easier if you just wanted to remote debug into it though
).Lots of little things being done, lots of function calls, pass a function that passes the pointer to a string "Armada.Execute" pretty early to help you get your bearings in the source, then realized that I was debugging into another loader app and not A2 (what is with the loader apps?) due to the Kernal32.OpenProcess call. I then decide to run Armada2.Execute for obvious reasons... Ignore the above I guess...
So, now running Armada2.Execute:
Wow, ugly freakin code, and a few exceptions being thrown even before the main loop is called thanks to some loaded dll's.
Once I got past those it seems the main app starts about at 00665E66.
The app installs a low-level structured exception handler to catch all uncaught exceptions, always a good thing (which your loader does not ever do I notice), ugly code, but well worth it.
Runs through some more of the standard Pre-WinMain crap it looks like.
It then calls some function deep within ntdll which then calls a function in non-readable memory (that is a new one on me...) thus even telling it to skip it does not work... how fun. Seems to be in ntdll.KiFastSystemCallRet, probably an exception handler, past the stuff I want...
Think I found the program's main function at 0046F720, so starting at this point now (this is before the non-readable error as stated on the previous line):
It first outputs a standard debug string of "NDEBUG defined.n".
It then creates then shows a window of Class type "Armada2Splash" (using my powers of deduction, I would have to say that this is the splash screen
). It then sleeps for 300ms for whatever reason (15ms should be fine to ensure a windows creation, or 35ms if on a 9x system, 300ms is way overkill, but whatever).A few calls after that the program dies again, starting to trace into functions before that now:
This first one I follow seems to create the logging functionality by getting the time information, creating a log file (seems to have support for datestamped log files too, which is does not use for whatever reason), and so forth. This function works and returns fine though it seems.
Next it oddly pushes a function pointer on the stack and calls another function, somewhere in this one is where the crash occurs, so tracing into it now:
In this function the first thing it does is set the low-level exception handler to an internal function that seems like it may be backed into this function itself, with a big ol' switch statement/table (and by big I mean big, it is FB in size).
It then calls a function pointer (looks like it might be the one that was passed on the stack, but did not really check close for sure). Somewhere in this function is where it crashes, so tracing into this one now, seems this function starts on: 0046F810
The first call in it is where the crash occurs, now tracing into it, this function starts on: 0047D5B0
Seems to set some low-level keyboard hooks (very odd I must say... usually will not work on non-admin accounts, but it looks like it has a fallback for that, so no big worry, but why use an llhook at all then?). No problems to here though.
It then does things like set its AI and Missions directory to the PATH environment var (why? any good game filesystem will not need nor use that...). However this is where things seem to go wrong, let me elaborate:
It is effectively calling sprintf like this in C code:
- Code: Select all
char *arg5 = "Q:Program FilesActivisionStar Trek Armada II"; // my installation directory for A2 obviously :)
char *arg4 = "Q:Program FilesActivisionStar Trek Armada II";
char *arg3 = "A_BLOODY_FREAKING_LONG_STRING_THAT_IS_MY_PATH"; // This may be the issue, described below...
char *format = "PATH=%s;%sAI;%sMissions;"
char some_unknown_size_string_buffer_horribly_horribly_unsafe_and_bad_programming[BUFFERSIZE]; // If you have an programming skills at all, your probably see the error already, after all, do you ever see a strlen being called on the above passed in args after all to ensure a buffer size?
// Remember that the prototype for sprintf is: int sprintf(char *str, const char *format, ...)
int return_value_is_ignored = sprintf(some_unknown_size_string_buffer_horribly_horribly_unsafe_and_bad_programming, format, arg3, arg4, arg5); // Mega crash, buffer overflow, horrible corruption, take your pick, it is all the above...
// Now, lets see what they *should* have called if the programmers were not utter dimwits instead of the sprintf line (although some C++ things would make this code stupid-simple, here is a C version):
size_t l = strlen(arg5) + strlen(arg4) + strlen(arg3) + strlen(format); // Still not perfect, but they would have to intentionally mess with things to screw this up and there are better ways to do that anyway, this will prevent accidental crashes like what is going on here perfectly though
char *string_buffer = (char*)mallac(l+1);
string_buffer[l] = 0;
int return_value_is_ignored = snprintf(string_buffer, l, format, arg3, arg4, arg5);
// do something with string_buffer, then free it
free(string_buffer)
As you can see, by my guess it seems that my system environment path of length 1721 characters is probably overflowing the buffer (which I bet they naively put at 1024 >.<; ). I am now going to test this by launching a2 through a command prompt while cutting my path to a normal couple hundred chars (just enough for windows to function well for A2 for certain). If it runs this is the problem, if not this problem still needs to be fixed regardless as it is a pretty bad bug, static buffers for external data, horrible horrible HORRIBLE mix, bad bad A2 programmers...
...
Now I test...
...
AND IT WORKS, THANK GOD.
Aren't you glad to have an external programmer/debugger sometimes.
Either way, I found a work-around, I'll just create a batch file to pre-set my PATH envar to something good for my system, you should have your patch fix that little bug in the next version because that is a pretty freaking huge bug that nothing else seems to have, probably because 'most' programmers learned long ago the horrors of static buffers with external data.
So yes, I gave you a detailed problem, the debugging path I went, and the fix, you have no excuse to fix; heck, if you want I could manually create the assembly in the executable to do it and have the function jump to that and back to fix the bug, I have done it in other commercial apps to fix bugs that are no longer being patched so I am no stranger to it, but as you are making newer 'unofficial' patches, this is something you really need to fix.
If you need help, email me at my username (OvermindDL1) at the normal gmail address.
I still cannot believe it was something as simple as a buffer overflow, some programmers really are lazy, wonder who originally wrote that function, guh...[br]Posted on: May 29, 2008, 02:33:50 AM
Also, I still cannot log into my OvermindDL1 account, still with the same above error, do not suppose you could fix that too, should be a simple DB edit (I've messed with the bridge before that you are using and encountered that bug, thought it was fixed long ago though, it is caused by changing your email address in your profile...).[br]Posted on: May 29, 2008, 02:35:44 AM
Also, if you are really cheap (and I really do *not* recommend this, but if you are going to do it, at least do it right), you could just have your loader set the envar PATH to "%WINDIR%system32" and it should work in 'most' circumstances, but maybe only do it if you detected the path being too long in the first place, say more then 500 chars to allow for the max path of 256 for the each of the passed in A2 directory strings and a little for the format string. Although this would work for anyone who does not have 'too' unusual of a setup (mine may be unusual, like my boot drive being F and so forth, but it is not *that* unusual for that to not work
), but it would not always work, and it would still be best to do the real fix I documented above.[br]Posted on: May 29, 2008, 02:53:21 AMYes yes, another thing, sorry...
I see resolutions like 1280x960, but I do not see 1280x1024, is there some file I need to change or something?
posted on May 29th, 2008, 8:37 am
Last edited by DOCa Cola on May 29th, 2008, 9:28 am, edited 1 time in total.
yea, thats the environment variable buffer overflow and it is fixed with the loader already, i am not sure though if it is fixed to as much as 1700 chars. you should strip down some never needed pathes from it... 
but i will see if i can write a better non-static fix for the next version. edit: just looked what we have done there and the function is fixed up to 512-1 chars instead of 260-1 (-1 -> null termination ). see 483ef9 and the rest of the function down below (fix edi) that address for that.
btw. disadvantages of a 'hard'patched armada 2 binary is that the online crc check won't allow you to play online and not over network anymore.
the integrated armada exception function actually did never launch in all the years i am working with armada 2, in the current version (patch project for example) an own exception engine is used there.
and yes our old loader is quite ugly written, please don't look at it too much xD
no, again, these are bugs/limitations in armada 2 and a 'resolution-free' patch is in the works/under testing currently.
i will see what i can do about your account login issue
but i will see if i can write a better non-static fix for the next version. edit: just looked what we have done there and the function is fixed up to 512-1 chars instead of 260-1 (-1 -> null termination ). see 483ef9 and the rest of the function down below (fix edi) that address for that.btw. disadvantages of a 'hard'patched armada 2 binary is that the online crc check won't allow you to play online and not over network anymore.
the integrated armada exception function actually did never launch in all the years i am working with armada 2, in the current version (patch project for example) an own exception engine is used there.
and yes our old loader is quite ugly written, please don't look at it too much xD
I see resolutions like 1280x960, but I do not see 1280x1024, is there some file I need to change or something?
no, again, these are bugs/limitations in armada 2 and a 'resolution-free' patch is in the works/under testing currently.
i will see what i can do about your account login issue
posted on May 29th, 2008, 8:56 am
Last edited by DOCa Cola on May 29th, 2008, 9:19 am, edited 1 time in total.
you should be able to login with your old account now, however you need to use the 'lost password' form as i had to reset it.
if you still have login issues, you can write me an email directly or contact me via IM
btw. welcome back to the forums
if you still have login issues, you can write me an email directly or contact me via IM
btw. welcome back to the forums
posted on May 29th, 2008, 10:15 am
Last edited by OvermindDL1 on May 29th, 2008, 10:17 am, edited 1 time in total.
Ah, thanks much with the account.
And yes, I kinda need my long path, it is trimmed down from what it was a few months ago. >.>
One of the many curses of the programmer I guess...
I just made a quick launcher for your launcher (of A2, also, I was commenting how ugly the A2 code was, not your launcher, the launcher was actually quite easy to follow, A2 was... well... horrid) made up of the following code, nothing special:
With the appropriate headers included of course, prefer this over a batch script as batch scripts do not work with yet another launcher I use (Steam, I like the overlay, so sue me... what is that now, 3 launcher of launcher depths?) does not support bat files, only executables.
And yea right, forgot about that, that your patch is compatible with people running 1.1 as well.
I was noticing that too, A2 did seem to successfully set the low level exception handler, I wonder why it was not being called for the buffer overflow. When I traced it, it did enter an exception handler, so something *is* catching it, but I did not trace any further to see what it did with it (was not so interested as what happened to the error message, but rather what caused it after all ).
But yea, if you cannot tell I tend to be a perfect example of reasons why not to hard-code buffers and other such things. Oddly enough I have always been rather allergic to hard-coding buffers in my own programs, I just cannot bring myself to do it, along with other stupid things like expecting that a C: drive exists (I do not have a C drive, I do however have everything from D to R filled with local partitions, and Y and Z are network shares, the boot drive being on F and the page file being on G; no I did not design it like this, this is just how it kind of evolved over time, I did start out with a normal C boot and all such, just this system mutated over the years...).
Still can't believe that it was just a stupid buffer overflow all these years; could kick myself for not noticing it last time...
And yes, I kinda need my long path, it is trimmed down from what it was a few months ago. >.>
One of the many curses of the programmer I guess...
I just made a quick launcher for your launcher (of A2, also, I was commenting how ugly the A2 code was, not your launcher, the launcher was actually quite easy to follow, A2 was... well... horrid) made up of the following code, nothing special:
- Code: Select all
int APIENTRY _tWinMain(HINSTANCE ,
HINSTANCE ,
LPTSTR ,
int )
{
_putenv_s("PATH", "%WINDIR%system32");
const char *arg1 = ".FleetOps.exe";
const char *arg2 = ".";
ShellExecute(NULL, NULL, arg1, NULL, arg2, SW_SHOWNORMAL); // I tend to avoid casting when possible, hence the const char's instead of just embedding it as arguments directly
return 0;
}
With the appropriate headers included of course, prefer this over a batch script as batch scripts do not work with yet another launcher I use (Steam, I like the overlay, so sue me... what is that now, 3 launcher of launcher depths?) does not support bat files, only executables.
And yea right, forgot about that, that your patch is compatible with people running 1.1 as well.
I was noticing that too, A2 did seem to successfully set the low level exception handler, I wonder why it was not being called for the buffer overflow. When I traced it, it did enter an exception handler, so something *is* catching it, but I did not trace any further to see what it did with it (was not so interested as what happened to the error message, but rather what caused it after all
).But yea, if you cannot tell I tend to be a perfect example of reasons why not to hard-code buffers and other such things. Oddly enough I have always been rather allergic to hard-coding buffers in my own programs, I just cannot bring myself to do it, along with other stupid things like expecting that a C: drive exists (I do not have a C drive, I do however have everything from D to R filled with local partitions, and Y and Z are network shares, the boot drive being on F and the page file being on G; no I did not design it like this, this is just how it kind of evolved over time, I did start out with a normal C boot and all such, just this system mutated over the years...).
Still can't believe that it was just a stupid buffer overflow all these years; could kick myself for not noticing it last time...
Who is online
Users browsing this forum: No registered users and 34 guests