An inaccuracy due to working too fast, messed up a fix for the broken building output types economic-, scientific- & military-intel.
My test versions, created via OllyDbg, mostly have names like f.e. trek1.exe. In this special case, the faulty exe only freezes the game when named exactly trek.exe. A strange observation.
This leads to the question of the technical relevance of the file name, since said code has nothing to do with stuff like f.e. tactical combat i.e. external dll files with filename references (at least AFAIK)?
Relevance of the trek.exe filename?
Moderator: thunderchero
- Spocks-cuddly-tribble
- Code Master
- Posts: 1884
- Joined: Sun Apr 27, 2008 2:00 am
Relevance of the trek.exe filename?
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
- Flocke
- BORG Trouble Maker
- Posts: 3197
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: Relevance of the trek.exe filename?
Huh, well I do the same and it really shouldn't matter what name it is. If there was a file reference it should rather cause problems if you name it different than trek.exe.
What can be is that there's a firewall/av-software that identifies the file by it's name and is causing issues. Or windows itself, maybe for some strange reason it handles the file different.
I mean it can be a random bug caused by loading to a slightly different memory space or something. Things sometimes become really weird if you e.g. access wrong memory space.
can't tell ya, sry
What can be is that there's a firewall/av-software that identifies the file by it's name and is causing issues. Or windows itself, maybe for some strange reason it handles the file different.
I mean it can be a random bug caused by loading to a slightly different memory space or something. Things sometimes become really weird if you e.g. access wrong memory space.
can't tell ya, sry
- QuasarDonkey
- Code Analyst
- Posts: 433
- Joined: Tue Jul 26, 2011 8:29 pm
- Location: Ireland
Re: Relevance of the trek.exe filename?
I agree, filename shouldn't matter.
It has happened to me before that Trek.exe will freeze/crash when I try to run it while it's loaded in Ollydbg. It usually only happens if I have run Trek.exe within Olly, and then make some changes. Even running Trek.exe outside Olly will cause a crash. If I quit Olly, it works again.
I think if you finish debugging with Olly, the process is still loaded in memory (you have to go File -> Close to terminate process). I often do what you do (Trek1.exe, etc.), and then replace the original while Olly is still running. But maybe the O.S. sees Trek.exe in memory, and uses the old version that Olly has loaded?
It has happened to me before that Trek.exe will freeze/crash when I try to run it while it's loaded in Ollydbg. It usually only happens if I have run Trek.exe within Olly, and then make some changes. Even running Trek.exe outside Olly will cause a crash. If I quit Olly, it works again.
I think if you finish debugging with Olly, the process is still loaded in memory (you have to go File -> Close to terminate process). I often do what you do (Trek1.exe, etc.), and then replace the original while Olly is still running. But maybe the O.S. sees Trek.exe in memory, and uses the old version that Olly has loaded?
- Flocke
- BORG Trouble Maker
- Posts: 3197
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: Relevance of the trek.exe filename?
Right, now that you say, I remember that as well. Must be an allocation conflict of some kind.QuasarDonkey wrote:It has happened to me before that Trek.exe will freeze/crash when I try to run it while it's loaded in Ollydbg. It usually only happens if I have run Trek.exe within Olly, and then make some changes. Even running Trek.exe outside Olly will cause a crash. If I quit Olly, it works again.
- Spocks-cuddly-tribble
- Code Master
- Posts: 1884
- Joined: Sun Apr 27, 2008 2:00 am
Re: Relevance of the trek.exe filename?
@ firewall/av-software: No. I have low priority stuff like BotF on a computer without any protection and almost all services disabled.Flocke wrote:What can be is that there's a firewall/av-software that identifies the file by it's name and is causing issues. Or windows itself, maybe for some strange reason it handles the file different.
I mean it can be a random bug caused by loading to a slightly different memory space or something. Things sometimes become really weird if you e.g. access wrong memory space.
@ windows(in this case XP): The OS was my guess too.
@ slightly different memory space: Yes, a register typo, causing a read-from address diviation of about slightly 12 million bytes... But the bug itself was no problem (intel project is finished ), just the strange behavior deviation due to filename is confusing.
Checking such things (before posting/asking) is self-evident and base for any conversation. So a clear no.QuasarDonkey wrote:maybe the O.S. sees Trek.exe in memory, and uses the old version that Olly has loaded?
The conclusion from the incident (for my PC) is always naming the newest test version trek.exe, since maybe some sort of OS error correction trial (sometimes mentioned by OllyDbg?) unveiled a serious bug which otherwise remained undetected (i.e. much more work later).
An unrelated/unimportant question wrt recource consumption (*mul/*div):
I just skimmed through a few links like the following, but couldn't find hints if there is a mentionable difference between integer arithmetics & FPU?
http://forum.doom9.org/archive/index.php/t-132380.html
Also these nerds show a visceral antagonism to come short and clear to the point, worse than a sewing circle^^. Any hints on how to set this sort of folks back on the right path... treating with a pair of pliers and a blow torch?
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
- Flocke
- BORG Trouble Maker
- Posts: 3197
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: Relevance of the trek.exe filename?
@intel project: great to hearSpocks-cuddly-tribble wrote:@ slightly different memory space: Yes, a register typo, causing a read-from address diviation of about slightly 12 million bytes... But the bug itself was no problem (intel project is finished ), just the strange behavior deviation due to filename is confusing.
@strange behaviour: don't be too much confused. That kinda weird results can happen if you access an unallocated memory space.
Depending on the memory location the game gets loaded to, you access a different place in ram memory. And depending on the filename, windows probably loads the exe to a different location.
So it's probably just bad luck naming it "trek.exe" crashed the game (or good you detected the bug).
You might find other names that result in crashes as well. And when you reload your system things might change.
windows os internals are a hidden secret with strange windings, not that I know more on linux internals.
Well, talking to genious Tribble that might be, but remember us 'normal brains' one time might conceal to tell you of a major importance cause we got wrong in assuming it would be self-evident to you.Spocks-cuddly-tribble wrote:Checking such things (before posting/asking) is self-evident and base for any conversation. So a clear no.QuasarDonkey wrote:maybe the O.S. sees Trek.exe in memory, and uses the old version that Olly has loaded?
In other words, it doesn't harm to mention, does it?
Do so, but as a programmer I've to say that it would withdraw from any plausible logic to me, if naming it 'trek.exe' would be more error detective than other names.Spocks-cuddly-tribble wrote:The conclusion from the incident (for my PC) is always naming the newest test version trek.exe, since maybe some sort of OS error correction trial (sometimes mentioned by OllyDbg?) unveiled a serious bug which otherwise remained undetected (i.e. much more work later).
Depends on cpu design, but commonly integer arithmetic is faster than floatingpoint and multiplication normally is faster than division. To get a factor I'd have to set up some tests, dunno. But if the calculation isn't done a million times it shouldn't make too much of a difference. To improve general speed you do better in trying some performance profiling to identify code causing slowdowns.Spocks-cuddly-tribble wrote:An unrelated/unimportant question wrt recource consumption (*mul/*div):
I just skimmed through a few links like the following, but couldn't find hints if there is a mentionable difference between integer arithmetics & FPU?
http://forum.doom9.org/archive/index.php/t-132380.html
Also these nerds show a visceral antagonism to come short and clear to the point, worse than a sewing circle^^. Any hints on how to set this sort of folks back on the right path... treating with a pair of pliers and a blow torch?
P.S. @nerds forum: what, are you interested in mmx coding now?
I pretty much understand nothing from what they write over there and have no motivation for it either.
- Flocke
- BORG Trouble Maker
- Posts: 3197
- Joined: Sun Apr 27, 2008 2:00 am
- Location: Hamburg, Germany
- Contact:
Re: Relevance of the trek.exe filename?
interestingly I stumbled about some naming issue today while fiddling with trek.exe
I had the pseudo window mode patch applied and when not named exactly trek.exe it crashed iterating the render devices/resolutions
causer was, for trek.exe I already had the windows 16bit mode compability applied, and I had to reapply it for the renamed file
I had the pseudo window mode patch applied and when not named exactly trek.exe it crashed iterating the render devices/resolutions
causer was, for trek.exe I already had the windows 16bit mode compability applied, and I had to reapply it for the renamed file