Relevance of the trek.exe filename?

This forum contains threads from main General Chat forum older than 3 months.

Moderator: thunderchero

Post Reply
User avatar
Spocks-cuddly-tribble
Code Master
Code Master
Posts: 1884
Joined: Sun Apr 27, 2008 2:00 am

Relevance of the trek.exe filename?

Post by Spocks-cuddly-tribble »

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)?
I don't know how many bugs is too many but that point is reached somewhere before however many in BotF is.
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3197
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: Relevance of the trek.exe filename?

Post by Flocke »

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
User avatar
QuasarDonkey
Code Analyst
Code Analyst
Posts: 433
Joined: Tue Jul 26, 2011 8:29 pm
Location: Ireland

Re: Relevance of the trek.exe filename?

Post by QuasarDonkey »

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?
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3197
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: Relevance of the trek.exe filename?

Post by Flocke »

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.
Right, now that you say, I remember that as well. Must be an allocation conflict of some kind. :roll:
User avatar
Spocks-cuddly-tribble
Code Master
Code Master
Posts: 1884
Joined: Sun Apr 27, 2008 2:00 am

Re: Relevance of the trek.exe filename?

Post by Spocks-cuddly-tribble »

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.
@ firewall/av-software: No. I have low priority stuff like BotF on a computer without any protection and almost all services disabled.

@ 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.

QuasarDonkey wrote:maybe the O.S. sees Trek.exe in memory, and uses the old version that Olly has loaded?
Checking such things (before posting/asking) is self-evident and base for any conversation. :wink: So a clear no.


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.
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3197
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: Relevance of the trek.exe filename?

Post by Flocke »

Spocks-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.
@intel project: great to hear :)
@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.
Spocks-cuddly-tribble wrote:
QuasarDonkey wrote:maybe the O.S. sees Trek.exe in memory, and uses the old version that Olly has loaded?
Checking such things (before posting/asking) is self-evident and base for any conversation. :wink: So a clear no.
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. :lol:
In other words, it doesn't harm to mention, does it?
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).
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. :roll:

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?
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.

P.S. @nerds forum: what, are you interested in mmx coding now? :lol:
I pretty much understand nothing from what they write over there and have no motivation for it either. :mrgreen:
User avatar
Flocke
BORG Trouble Maker
BORG Trouble Maker
Posts: 3197
Joined: Sun Apr 27, 2008 2:00 am
Location: Hamburg, Germany
Contact:

Re: Relevance of the trek.exe filename?

Post by Flocke »

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
Post Reply

Return to “General Chat Archive”