Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and ... - Page 4

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Ant I'm not a tech but I wonder if this means that Dustin's Exevalid may
not be able to find all valid executables. Is that right?

--  
Jax    :)

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

"Jax" wrote:

Quoted text here. Click to load it

Yes, some Windows executables. I've already said as much in other
posts.



Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

I didn't know about the effect of upack because it wasn't a packer that I'd  
seen that much of. I simply didn't care about it. It's *still not* as  
popular as UPX. The MZ size values are typically fine for the intended  
purpose of exevalid. A size reported smaller than the file is isn't a  
concern of exevalids. In this case, upack sets the header to be alot larger  
than a file is likely going to be and causes problems. I've repeated myself  
so many times it's not even funny, but I'll do it again once more:

EXEVALID wasn't made for precision, that was never even a factor. I DID  
know about the MZ header not being accurate for PE section, but I really  
didn't give a shit. It works fine for MZ stub files, true MSDOS  
executables, and semi okay for windows based ones.

As long as we're commenting concerning what you think everyone did or  
didn't know, you might want explain to pooh that his "math fix" wouldn't  
have resolved the issue. Which is still the same issue the original version  
has-It expects to see a normal MZ header.

--  
Take it easy... Don't let the sound of your own wheels drive you crazy.  
Lighten up while you still can. Don't even try to understand.  
Just find a place to make your stand and take it easy!


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

fix what stupid? Isn't that what you thought you did with your first fix?  

You've beaten me at everygame because you say so? Facts obviously don't  
agree, so that's the only thing you could declare, I guess.

Wot a wanker. Not only are you a script kiddie, you're also a very sore  
loser.

  



--  
Take it easy... Don't let the sound of your own wheels drive you crazy.  
Lighten up while you still can. Don't even try to understand.  
Just find a place to make your stand and take it easy!


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Pooh, your fix does nothing with upack'd executables or any other exe that  
isn't using a normal MZ header. Actually, you spent so much time worrying  
about the math routines, you skipped the reason it was doing any math in  
the first place. Let's not try to rewrite history by saying you knew what  
you were doing prior to not only my having to tell you, but google as well.

Despite that, you worked so hard on a demo that uses more resources and  
does less work for it, yet still has the same issue the original exevalid  
has. It can be tricked with bad header information. What's worse, your  
demos don't even try to see if the first two bytes they pulled actually is  
MZ. Now, I can save bytes by taking shortcuts like that too, but the result  
is a completely useless "demo" program.

Quoted text here. Click to load it

It was self evident that you didn't know what exevalid did when I posted  
the source code to it and asked you. The mystery routines and non existant  
routine claims you made told everyone the story. The days you've spent side  
tracking/deflecting from the original question changes nothing. The  
original question was can you tell us what the program is doing, and you  
could not do so.
  


--  
Take it easy... Don't let the sound of your own wheels drive you crazy.  
Lighten up while you still can. Don't even try to understand.  
Just find a place to make your stand and take it easy!


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Dustin you admit to not understanding the tech theory and that's why
Exevalid has so many flaws. Above you accept it's only "semi okay for
windows based [executables]"  

However that doesn't explain your unnecessary hostility and aggression  
toward Pooh Cat when he pointed out some of the bugs in Exevalid.  

Just accept Pooh Cat's tech feedback and stop your crazy argument that you
were right in every aspect all along.  

--  
Jax    :)

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

On 5/10/2014 10:55 AM, Jax wrote:
Quoted text here. Click to load it
How do you even know if someone else is right?  Because they told you?  
You've admitted you don't get this stuff.


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

"Dustin" wrote:

Quoted text here. Click to load it


I'm commenting about statements people make. You've just said you
didn't know about Upack. See my other post regarding what you
originally said about Win PEs.

Quoted text here. Click to load it

As I understand it there are two main issues:

 - A bug in ASIC, where 0x8000 isn't handled properly.
 - Some Win PE MZ headers contain other bad values.

The "math fix" wasn't intended to deal with the PE issue.



Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

I'm aware of that. See my previous post explaining things in as much detail  
as is needed.
  
Quoted text here. Click to load it

The math fix wasn't intended to deal with either issue. Pooh wasn't made  
aware of the other issue until I provided him the information. I've been  
holding his hand concerning the program for sometime now, when all I wanted  
to know was whether he understood what it was doing or not. He did not.

Pooh even expects credit for being the first person in asic to use high/low  
bytes as integers. Laughingly, workarounds like that have been performed by  
many asic programmers over the years. I've no claim to the originality of  
it anymore so than he does.

I didn't bother ever fixing the issue because I wasn't concerned with  
precision beyond a certain filesize. I've never actually seen any  
executable header that had 0080 for the blocks, myself.

Treating the bytes individually as high/low sections of an integer does  
resolve the issue, but Pooh wasn't writing it for that; he didn't know  
anything about it. I'm sure it probably messed with him for awhile tho, if  
he ever selected to use 0080 for any testing. I've no idea what his testing  
methodology is like.

Using the abs statement allowed the initial release to handle the situation  
fine, until the file was several megabytes in size; then some accuracy was  
lost. Pooh removed the abs statement initially and then noticed it wasn't  
working very well any more. He spent days messing with asic and the program  
until he learned about asic integers. After, I posted another demo showing  
how to go from short to long integers and back. That's when he declared  
he'd developed a "workaround" that was his original work. lol.  

There's alot of the discussion you missed man.


--  
Take it easy... Don't let the sound of your own wheels drive you crazy.  
Lighten up while you still can. Don't even try to understand.  
Just find a place to make your stand and take it easy!


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

"Dustin" wrote:

Quoted text here. Click to load it

So what was it intended to deal with?

Quoted text here. Click to load it

So why did he write it?

Quoted text here. Click to load it

If it doesn't go negative then why does several meg make a difference
to accuracy?

Quoted text here. Click to load it

Well I'm not digging around in groups I don't read to find the missing
pieces.



Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

"p-0''0-h the cat (ES)" wrote:

Quoted text here. Click to load it

Thanks for the clariification.

I can see now why abs() isn't suitable when you're supposed to treat
unsigned words as what they are; unsigned, a concept that apparently
is foreign to ASIC. e.g. if a word contains 0xFFFF the signed
interpretation of that is -1 whereas the unsigned interpretation is
65535. Doing an abs() on the signed variant should give you 1 which is
wrong when you're supposed to be looking as an unsigned range. Once
the most significant bit is filled, in the case of huge files or
invalid values, it becomes important to treat the values as unsigned
in the first place.



Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Ant..... thank you for your feedback. It's nice to have someone who has  
the expertise to comment and who is neutral.

It's interesting you say ABS isn't suitable because that's been the topic  
of a lot of debate. Dustin feels ABS is the best way to do it and doesn't  
heed Pooh Cat's advice or acknowledge his improvements to the code.

--  
Jax    :)

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

On 5/11/2014 10:42 AM, Jax wrote:
Quoted text here. Click to load it

You don't have the expertise to comment and yet you're doing it endlessly.



Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Linda..... you're jealous I started to learn programming a few months ago.

Me, Dustin and Pooh Cat are discussing ways to improve Exevalid. We don't
need snide comments from onlookers like you. You're not helping us.  

Now I have to go and review Dustin or Pooh Cat's latest code which you
probably wouldn't understand.  

--  
Jax    :)

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

On 5/12/2014 9:38 AM, Jax wrote:
Quoted text here. Click to load it


Learning a skill and being able to adequately address an issue are 2  
different things jackie.  There is absolutely nothing about you that I,  
or anyone for that matter, would be jealous of.

Quoted text here. Click to load it

Your statement above is just a lie.  You're not discussing anything.  
You are simply trying to demean Dustin as often as possible.  You have  
nothing to offer to the discussion other than insults.

Quoted text here. Click to load it
You can't review anything because, by your own admission, you don't  
understand it.  As for what I know, I wouldn't waste my time trying to  
explaining it to an imbecile like you.


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Linda you're jealous. What do you know about the mussed up
positive/negative numbers in Exevalid? Zilch. So leave this to those who  
have some idea. Just saying.

--  
Jax    :)

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

On 5/12/2014 2:13 PM, Jax wrote:
Quoted text here. Click to load it
Please do let us know when you show that you have some idea about any of  
this.  Why did you comment, more than once, that you didn't know what it  
was all about.

You're really reaching now jackie, and quite unsuccessfully.  You can't  
address what's raised so you attempt your childish diversion.  You're a  
joke, albeit not a funny one.  Just saying :)


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

127.0.0.1:

Quoted text here. Click to load it

ABS has been the topic of alot of debate. I didn't say ABS was the best way  
to do it, but it's certainly one way in which you can; as long as you  
understand the limitations when doing so. See ASIC.DOC, lookup the timer  
command. Or read here:

Dustin formulated the question :

[...]

Quoted text here. Click to load it

Here's the way I see it:

Person A puts up some code to show that person B is a poseur.

A) Here's a program I wrote for my C64 when I was in High School. It  
calculates the average age of students on a bus. Show us your  
understanding of this program, it's time to shine.

B) What are all the peeks and pokes about, and don't you know that goto  
is a no-no? It doesn't work anyway, it can't find some sort of school  
records. I tried to run it on my C64 emulator and it falls over. So, I  
decided to use only the part that calculates the average and give it  
some local data to work with and discovered that it gives bad results  
when there are more than 1024 students or if any of them are older than  
256 years in age.

My rewrite of your program only uses twice as much working space and is  
only 50% slower but it works for the entire school, students *and*  
staff.

C) Hey FTR, which program do you think is better, B's or A's?

D)<OBSESS>

Me) Assuming A's program doesn't work and B's does, of course B's is  
better. Assuming that they *both* work, then the faster smaller one is  
better. The fact that B's program works for the entire school,  
including Principal Methuselah and Vice Principal Moses is irrelevant  
to the task of calculating the average age of students on a bus, and an  
emulator doesn't prove that either program would have worked on actual  
hardware.

B) Whimper, sniffle, insult.

There, and I didn't mention any names. :)




--  
Take it easy... Don't let the sound of your own wheels drive you crazy.  
Lighten up while you still can. Don't even try to understand.  
Just find a place to make your stand and take it easy!


Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.

On 5/11/2014 1:36 PM, Dustin wrote:
Quoted text here. Click to load it
Except for Methuselah and Moses.  :-)

--  
Froz...


The system will be down for 10 days for preventive maintenance.

Re: Dustin fess up or you're fired. I asked for you to post tighter source than mine, and for it to be on my desk this morning. You have one hour.


Quoted text here. Click to load it

Which isn't accurate.
  
Quoted text here. Click to load it

Pooh knew nothing about it, and ASIC is aware of the condition. It's one
reason ABS is used. The timer command in asic.doc explains it.  

You do sacrifice proper integer representation beyond 65536 when you do
it, but it still ensures the number you're dealing with (unless you run
across the bug I mentioned, that again, Pooh knew nothing about) is a
positive integer.  

Quoted text here. Click to load it

 This statement will retrieve a timer count from the PCs hardware
 circuitry.  
     The timer count will be placed in number1.  The timer count is in
     "clock ticks".  A "clock tick" occurs in the PC approximately 18.2
     times per second.  The PC is continually incrementing this clock
     counter.  This statement can be used to time the duration of events.

     Example:

          CLS
          PRINT "PRESS A KEY"
          STARTCNT&=TIMER
     LOOP:     X$=INKEY$
          IF X$="" THEN LOOP:
          ENDCNT&=TIMER
          ELAPSED&=ENDCNT&-STARTCNT&
          ELAPSED&=ABS(ELAPSED&)
          ELAPSED&=ELAPSED&/18
          PRINT "IT TOOK YOU APPROXIMATELY";
          PRINT ELAPSED&
          PRINT " SECONDS TO PRESS A KEY"

     The above code fragment will time how long you wait to press a key
in  
     seconds.  You could modify it easily to display in clock ticks, which
     would provide much more accuracy, if you deleted the statement which
     divides the ELAPSED count by 18.

     Comments:

     Note that it is necessary to use the absolute value of ELAPSED&
since the  
     clock counts is stored as unsigned integers.  ASIC integers, on the
     other hand, are signed.  If number1 is a long integer variable, then
     TIMER retrieves the full PC timer value.  However, if a normal
     integer variable is specified as number1, then ASIC retrieves the
     least 16 significant bits from the PC timer.




--  
Take it easy... Don't let the sound of your own wheels drive you crazy.
Lighten up while you still can. Don't even try to understand. Just find a
place to make your stand and take it easy!  


Site Timeline