You've already proven not to know what you're missing with your earlier cache-statements. I'm not exactly here for you.


I realize that I have alot to learn, I just have nothing to learn from you. You are an asshole and distasteful and I would remain ignorant before I would consider anything you said. I will continue to read and take my lessons from the likes of f0dder and bitRake and NaN and I will continue to laugh at you and pity your attittude and the waste of skin that surrounds it.
Posted on 2004-02-19 03:25:54 by donkey
Poor old scali, still can't take a trick. Iczelion started the win32asm community and notty and masta started the win32asm IRC channel, who the PHUK was scali ?

Gattling => Xcalibre => Scali

You will never win an argument with me as long as your arsehole points to the ground because you start with the wrong premise that you are actually smart enough to stand over someone.

You have kept insulting Harold with your bad manners and abuse of other people and even after you have been banned again, you rejoin under another phony name and keep it up.

It would not matter if you were God's gift to programming which in fact you aren't, your approach continues to display that you are not as good as you would like to claim to be and every time you perform another childish tantrum, you just prove it again and again.

It may have been OK years ago to be a passenger on Ewald who was a very good assembler programmer and some time after being a passenger on Michael Kalms who is a very well know graphics programmer but at the bottom line, to be the highly self acclaimed guru you want to be seen as, you have to deliver in the performace area and you don't have the talent to do it.

If you could learn to shut your mouth and write some decent code instead, you would actually get somewhere but its your mouth that keeps getting you into trouble and it appears you don't have enough brains to realise that and keep shooting it off time after time.

I wonder how many more times you will join this forum to abuse its members and insult Harold with your conduct ?

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-02-19 03:34:10 by hutch--
If anything, you'd probably be working for me...

Yea, right. I've been in this business for 35 years. How long have you been at it, junior?

But you're right, I couldn't work for someone like you. You just bitch and bitch and bitch, and bitch and bitch and bitch, then bitch some more. Talk about ego...

Look, I don't care about your history. All I care about is what I see going on now. You take a simple question, like this thread, and turn it into a 1,000 page novel.

I don't hate anyone, including you. But I don't think any of us come here to see this crap, over and over again.

Ever if you are right, you've got to learn when to shut up.

It's really too bad. You do seem like a pretty smart guy. Most likely you could make some good contributions here.

But this BS has just got to stop. Life is too short...
Posted on 2004-02-19 03:38:13 by S/390
S/390,

Arguing with a kid like this is a waste of gas, I know people like yourself have forgotten more than he knows but you cannot assume a reasonable person here who listens to common sense. I have seen his appalling performances for years on IRC then his attempts to continue them here.

We used to call them script kiddies back then but the IRC medium was so badly abused that the only successful method of supporting assembler programming is to run a moderated forum where idiots like this get arseholed out when they misbehave.

Unfortunately Harold will have to deal with this problem as the continued abuse of his efforts in maintaining this forum effect how effective it is.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-02-19 03:47:47 by hutch--
The moral of the story always is that if your means of delivering isn't good, nobody will listen to what you have to say.

You're not welcome here anymore, so don't come back to the thing you label as "something you don't care about" and move on.


(a cookie for anyone identifying the movie where the post subject came from ;) )
edit: it's been dealt with, I hope it'll be sufficient.
Posted on 2004-02-19 03:49:33 by Hiroshimator
Yea, I hear ya hutch.

Maybe some day he'll grow up.

It really is a shame. He is a smart guy, and he could be a valuable resource.

But he's got to learn how to get along with the rest of the world first.

Imagine, if he put as much energy into actually doing something, as he does "bit picking"... ... ... :grin:
Posted on 2004-02-19 03:58:56 by S/390
ROFL :grin:
.686

.MMX
.XMM
.MODEL FLAT, STDCALL
OPTION SCOPED
OPTION CASEMAP:NONE

INCLUDE C:\masm32\include\windows.inc
INCLUDE C:\masm32\include\kernel32.inc
INCLUDELIB C:\masm32\lib\kernel32.lib
INCLUDE C:\masm32\include\user32.inc
INCLUDELIB C:\masm32\lib\user32.lib

.CODE

@str macro _str:vararg
local @@1
if @InStr(1, <_str>, <!"> )
.data
@@1 db _str, 0
.code
exitm <offset @@1>
else
exitm <_str>
endif
endm

@preverse MACRO ParList:REQ
LOCAL Value, arg
Value TEXTEQU <>
% FOR arg, <ParList>
Value CATSTR <arg>, <,>, Value
ENDM
Value SUBSTR Value, 1, @SizeStr( %Value ) - 1
Value CATSTR <!<>, Value, <!>>
EXITM Value
ENDM

xcall MACRO function:REQ, parameters:VARARG
LOCAL paddr
IFNB <parameters>
% FOR param, @preverse(<parameters>)
IF @SizeStr(<param> ) GT 4
paddr SUBSTR <param>, 1, 5
IFIDNI paddr, <ADDR >
paddr SUBSTR <param>, 6, @SizeStr(<param>) - 5
lea eax, paddr
push eax
ELSE
push @str(<param>)
ENDIF
ELSE
push @str(<param>)
ENDIF
ENDM
ENDIF
call function
ENDM

start:

xcall MessageBox, 0, "message", "title", MB_OK+MB_ICONEXCLAMATION

invoke ExitProcess, 0
ret

END start
slightly modified http://www.asmcommunity.net/board/index.php?topic=6187&perpage=15&highlight=xcall&pagenumber=1

:grin:

I believe this satisfies the main problem
invoke funcname, "This is a string"
:wave:

not something like
invoke funcname, somemacro("This is a string")
:grin:
Posted on 2004-02-19 04:00:09 by arkane
Josh,

Nice macros, why didn't you write them earlier so I did not have to write the ones in the macro file in MASM32.

This is how I did it.


reparg MACRO arg
LOCAL nustr
quot SUBSTR <arg>,1,1
IFIDN quot,<"> ;; if 1st char = "
.data
nustr db arg,0 ;; write arg to .DATA section
.code
EXITM <ADDR nustr> ;; append name to ADDR operator
ELSE
EXITM <arg> ;; else return arg
ENDIF
ENDM

This macro is called by the following "fn" macro

fn MACRO args:VARARG
LOCAL cnt
cnt = 0
arg equ <>
FOR var,<args>
arg CATSTR arg,<var> ;; get the proc name as 1st arg
EXITM
ENDM
FOR var,<args>
IF cnt gt 0
arg CATSTR arg,<,reparg(var)> ;; replace quotes and append arg
ENDIF
cnt = cnt + 1
ENDM
invoke arg
ENDM


Main difference is it still uses invoke so you get the type checking as well.

You may like this one, its the opposite of the first macro and it prevents a user from using quoted text where it should not be used. A form of type checking.


tstarg MACRO arg
quot SUBSTR <arg>,1,1
IFIDN quot,<"> ;; if 1st char = "
% echo arg ** QUOTED TEXT ERROR ** memory address expected
.ERR
ELSE
EXITM <arg> ;; else return arg
ENDIF
ENDM


Damnit, you could have saved me all that work. :grin:

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-02-19 08:41:22 by hutch--

Basically if the macro is not called from the code section as a programmer writes the code, direct writing in the data section works fine so I don't see the point.

errorstrings_start:
dd CTEXT("Error Message #1")
dd CTEXT("Error Message #2")
; ...
errorstrings_end:

- so there is a point. Besides, why not fix the macro when it has no bad side effects, but allows stuff like this?


The reason why I aligned the exit but not the entry was that BYTE data is hapily read at BYTE alignment when the following entry in the data section may be a DWORD or similar where the alignment actually matters.

What about speed-optimized string copiers? While the alignment is irrelevant for API calls, initializing local buffers with string constants, or appending string constants to buffers, could benefit from string alignment.

S/390...

Go think about your people skills for a while, and leave us alone.

He definitely does need to do that... he manages 'sorta okay' these days though, as long as hutch isn't involved ^_^ (and I still think that hutch'es manipulative & patronizing crap is a lot worse than whatever emotional outbursts scali have).
Posted on 2004-02-19 10:55:14 by f0dder
Well, since scali was banned again...


<Scali> boyer moore works smarter, not harder.
<hutch--> testing says otherwise, try it on 100 meg strings
...snip...
<hutch--> same problem it was designed at HLL, too much overhead
...snip...
<hutch--> I know the theory, its overhead kils it


(quite a while passes, and hutch finally (miraculously) gets the idea that boyer-moore is actually a nice algorithm)


Contrary to our friend's assertion, I did not need any other help as the original authors wrote the original code in PDP10 assembler back in the 70s.


... am I the only one seeing a mismatch between "designed at HLL" and "original code in PDP10 assembler"? I think it would be funny seeing the logs of bl0rght trying to explain boyer-moore to hutch, as she's a pretty friendly person with a lot more social skill than scali - but even she (as most other) failed to get through hutch'es thick skull, it seems. Fun that he emerges years later with Teh LEET asm0r versions of BM.

The comment about being a Passenger on Ewals and Kalms... bum bum. Sounds like you haven't seen anything scali has done for a couple of years. The java software 3D rendering demo was pretty cute. His toying around with multi-pass 3D hardware rendering has been cute to watch too, especially the field-of-vision stuff. Oh, and the marching cubes stuff... all of it runs rather well, and as far as I know, it was written from scratch from tech papers... rather than ripping off other people's code, or just blindly translating C examples to ASM.

Before anybody belittles this, you might want to have a look at some of the tech papers, especially on marching cubes. Or does scali have to write an assembly version of BoyerMoore before you care to even find out what marching cubes are about? ^_^

Oh, and btw, am I the only one thinking that virogen==vg==Jeremy Collake? :rolleyes:
Posted on 2004-02-19 17:30:03 by f0dder
f0dder,

As you choose to try and continue this argument as scali's proxy, try reading the old log posting in context. Since I actually do renember the conversations from back then, I heard a lot about how fast a BM was but no-one who could produce the code, the documentation or the research to back it up.

The one exception was Jeremy Collake who coded a variation of a Michael Abrash BM algo in 32 bit who published it back around that time.

Now actually bother to read the outrageous bullsh*t in that old log and you will find your friend making the assertion that you can scan a 600 meg CD with a BM in a very short period yet any script kiddies knows that the read and seek time for 600 meg of data from a current CD is still into the many seconds to minutes time frame.

When you are faced with obvious bullsh*t at this level, you in fact take no notice of it. What I did after being bored sh*tless with the bullsh*t was to research the available info I could find and with early examples that were available, a classic byte scanner beat them in almost every case.

Faced with a barrage of platitudes and bullsh*t from people like your friend, the place to get the technical data was from the French site maintained by Theirry La ? (La Crox from memory) which had a wide range of examples written in ANSI C.

The other source of info was the two original authors Bob Boyer and Moore, both professors at the big UNI in Texas who were more than happy to help.

With high quality information from well documented university sites and assistance from the original authors did I need some snotty nosed kid ranting and raving on IRC as a technical advisor ?

I had a use at the time for the research and produced a set of algos that were completely unrelated to anything alse on the market that handled the range of the original designs of the authors.

Some of the assertions were also naive in that BM algos are not all that flexible and have well known problems in certain contexts. They have a lead time to scan the required search word and then construct the 256 character table and they are directly slower on patterns of 6 bytes and under on any source length.

The majority of string searches are performed on relatively short sections of text and here a byte scanner is faster. A byte scanner is effectively linear under almost all conditions where a BM has wide time variation due to the character order of the pattern.

Worst case for a BM is very bad where the worst case for a byte scanner varies very little from a normal case.

Where a BM outperforms anything else is with large patterns on very large sources as long as the character distribution is not badly skewed. Uses are scanning entire drives for known virus patterns and scanning very large source for recognisable pattern of specifc types of data.

When your friend makes the assertion that he contributed to development of these algos, he is right to this extent that the bullsh*t coming out of him in this area was so blatant that I went looking elsewhere and found high quality technical data from people who actually knew what they were talking about.

If you acually bother to read the old log you will notice a pattern that most people learnt on IRC before they abandoned it, don't listen to script kiddies shooting their mouth off.

Regards,
http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-02-19 18:20:03 by hutch--

As you choose to try and continue this argument as scali's proxy, try reading the old log posting in context. Since I actually do renember the conversations from back then, I heard a lot about how fast a BM was but no-one who could produce the code, the documentation or the research to back it up.

Obviously I'm going to proxy for him, since he's not in a position where he can defend himself, and you're writing some things that are... plain wrong.

So you missed the few lines about bl0rght searching through an ISO file in a few seconds? ^_^ - yes, an ISO FILE, aka CD IMAGE, aka thing you have on your harddrive. I wonder how you would use Boyer-Moore on "a CD" anyway :rolleyes: (CreateFile with \.\x: ? We weren't on NT back then, don't think even bl0rght was.)

I certainly don't hope you're calling bl0rght a "snotty nosed kid ranting and raving on IRC" - and she did try to explain the algorithm to you, didn't she? (Oh, and if you cared to listen to people every once in a while, you'd probably have fixed that UnmapViewOfFile bug earlier, too. You kept on ranting against microsoft even after several people on this board had pointed out your error.)


The majority of string searches are performed on relatively short sections of text and here a byte scanner is faster.

I don't think anybody suggested BM is the holy grail for all kinds of searches... but it's obviously a very good algorithm for the situations where it's applied, otherwise it wouldn't have survived since the dark ages. If you look back to the logs, you will see:

<hutch--> its fast enough, overlaps Boyer Moore with no problems
...
<Scali> boyer moore kills it on large searches

- I don't think you'll be disagreeing (these days, anyway) that BM does pretty well for large strings?


Where a BM outperforms anything else is with large patterns on very large sources as long as the character distribution is not badly skewed. Uses are scanning entire drives for known virus patterns and scanning very large source for recognisable pattern of specifc types of data.

...And scanning through ISO images ;). Besides, using it for virus patterns is just about useless, as you need dynamic signatures and heuristic code analysers to catch todays virii.


When your friend makes the assertion that he contributed to development of these algos

Where does he do that? While cocky, all I see is him saying that BM is better for large strings, and that you must have looked at bad implementations if benchmarks showed otherwise. Did scali make any false claims about BM in that little log snippet?


don't listen to script kiddies shooting their mouth off.

hutch makes optimized bytescanner (which does work fine for small strings, indeed). hutch talks a lot about bytescanner. bl0rght, scali, and probably JC/vg notices and suggests (in polite and less polite ways) that BM is a better algo for large strings. Lots of nonsense follows. Now who were shouting their mouths off?

Oh, before you write off stuff like Marching Cubes as 'graphics junk', take a look at this: http://www.crd.ge.com/esl/cgsp/projects/medical/ - that's one of the applications of the MC algo: medical imaging. "It allows the doctor to fly through the colon without having to shove a camera up the arse of the patient." - how's that for useless junk? :rolleyes: . If you look at the algorithm description, it should also be clear that it's not all that trivial, and requires some skill to get running at decent speed, whether you do it in C or Assembly.

I don't really expect you to read through all this, nor even understand it fully, but I'm sure other people will.
Posted on 2004-02-19 19:20:05 by f0dder
smile,

Obviously I'm going to proxy for him

With this matter settled, I can respond on the basis of birds of a feather in bed together.

I certainly don't hope you're calling bl0rght

No, you and your buddy will do. bl0rght was always both very smart and gracious, something that neither of you have managed.

<Scali> boyer moore kills it on large searches

It actually depends on the pattern length and how the search is done. Try finding short patterns in a few million different strings, something for example that you do in very large log files. When you and your buddy dilute your ignorance some, you will draw the distinction. There are enough places where a byte scanner eats a BM alive, both of you need to learn this and there is nothing "smart" in the choice of an algo design that fails badly in known cases.

Now for the log file without the selective quoting.

<hutch--> its fast enough, overlaps Boyer Moore with no problems
*** owned0 has quit IRC (Read error: 0 (Undefined error: 0))
<SpanxMFCS> sorry to be harassing u at end of hard day
*** sat0r^zZZ (~me@astnet3.astelit.ru) has joined #win32asm
<Scali> hutch--: Urm?
<SpanxMFCS> are you making or breaking the encryption dude?
<Scali> hutch--: That silly rubbish with that loop?
<hutch--> making
<Scali> boyer moore kills it on large searches
<hutch--> which one ?
<wrightie-> l8er
<Scali> boyer moore works smarter, not harder.
<hutch--> testing says otherwise, try it on 100 meg strings
<Scali> it's the best searcher known to man.
<SpanxMFCS> lol
<SpanxMFCS> u guys are funny
<Scali> hutch--: Then the implementation reeks.
<hutch--> yes but ofen slower
<SpanxMFCS> debating speeds of string searches
<Scali> hutch--: go talk to blorght
<SpanxMFCS> hehehehe
<Scali> hers kicks total butt
<hutch--> same problem it was designed at HLL, too much overhead
*** wrightie- has quit IRC (Don't be so sad: I'll be back... )
*** DarkSheep (DarkSheep@pC19F36CE.dip.t-dialin.net) has left #Win32Asm
<hutch--> its the tests I am interested in
<Scali> hutch--: Honestly, do you understand the algo?
<hutch--> yes, its overhead heavy
<Scali> I don't think you do, else you would KNOW that it was the fastest hands
down.
<Scali> it has way less memory access
<Scali> which is the bottleneck
<hutch--> has problems with large occurrences of the leading string
<Scali> no, that's yours
<Scali> not boyre
<Scali> anyway, I see that yet another coder is clueless about algos...
<hutch--> mine has problems with the trailing string
<Scali> Time for breakfast.
<hutch--> haha
<hutch--> let me test yours
<Scali> hutch--: you check every byte man!
<SpanxMFCS> scali is cheeky ;p
<Scali> it CAN NOT be fast
<Scali> Just think!
<Scali> damnit!
<hutch--> I benchmark mine
<Scali> think!
<hutch--> clock says different
<Scali> clock my arse.
<hutch--> much less overhead
<endo|ZzZz> heh
<hutch--> per loop
<endo|ZzZz> well, im going to bed for real
<Scali> Like I said, blorght could find a file in a 650 mb ISO in 4 seconds
<endo|ZzZz> nite
<Scali> you do that with your searcher
<hutch--> seeya
<Scali> will take ages
<hutch--> from what, no CD is that fast
<Scali> hutch--: GRRRRRRRRRRRR!!
<Scali> YOU DON'T GET IT!!!
<hutch--> and how was it tested, in linear memory ?
<Scali> Boyer moore doesn't HAVE TO READ THE ENTIRE CD!!!!
<Scali> That's the beauty man!
<Scali> that's why it's so damn fast!
<hutch--> I have 4 Boyer moore inplementations here
<hutch--> they are SLOW at some stuff
*** faster has quit IRC (EOF of client)
<hutch--> neither does mine
*** CrashAway (~crashtest@pierramenta.imag.fr) has joined #win32asm
<CrashAway> mmm... no topic ?
<hutch--> the theory does not match the practice
<Scali> hutch--: Practice is searching an ISO in 4 secodnds
<Scali> you can NEVER do that.
<Scali> Boyer can
<hutch--> never seen it done, 650 meg in 4 seconds, haha
<Scali> hutch--: Talk to blorght
<SpanxMFCS> hutch: thanks again
<SpanxMFCS> nite all
<Scali> she can at least think
<hutch--> np spanx
<Scali> And code it
<hutch--> I hear it but I never saw it, all the BMs I have are not fast
<Scali> hutch--: Damnit, I thought you were leet
<Scali> BM does NOT search 650 mb
<Scali> Don't you get it?
<hutch--> I am a primitive, thats asm for you
<SpanxMFCS> scali: hes had a hard day, give him a break ;p
<SpanxMFCS> try him tomorrow
<hutch--> I know the theory, its overhead kils it
<Scali> SpanxMFCS: We've been through this a few times... vg told me he
explained the algo.
<SpanxMFCS> ok say 'good nite spanx' or 'goodbye spanx'
<Scali> Guess he did a lousy job
<hutch--> reading backwards is SLOW
<Scali> hutch--: Why?
<Scali> Cache can handle that
<hutch--> I have both of viro's
*** faster (~bored@will.always.have.a.Need-4-Speed.net) has joined
#win32asm
<hutch--> benchmarked against them
<Scali> besides, you don't read NEARLY as much as with your algo
<Scali> Well, then mebbe viro isn't leet either
<Scali> blorght is
<SpanxMFCS> good night spanx, sleep well spanx
<hutch--> it reads it a lot faster
<hutch--> seeya spanx
<SpanxMFCS> heeh thanks
*** owned0 (bored@OwnZ.yER.localh0.st) has joined #win32asm
<Scali> Blah, ASM will do you no good if you can't use a smart algo.
<hutch--> I am willing to benchmark it, the rest is hot air
<hutch--> its ancient tech based on C
<Scali> hutch--: If you would understand BM, there would be no need for
benchmarking.
<Scali> it's just SO F*CKING OBVIOUS
<Scali> doh
*** SpanxMFCS has quit IRC (hutch IS LEET!! )
<hutch--> its the only test
*** Scali is now known as Scalefood
<Scalefood> buncha llamaz here


Now for my comments on the statements from the self appointed oracle of #win32asm.


<Scali> hutch--: That silly rubbish with that loop?

This is analysis ?

<Scali> boyer moore kills it on large searches

Which ones ?

<Scali> boyer moore works smarter, not harder.

There is nothing smart about using it in the wrong place where it is slower.

<Scali> it's the best searcher known to man.

Until a faster one is applied to the situation being searched.

<Scali> it has way less memory access
<Scali> which is the bottleneck

This is bullsh*t, when a BM is faster, it is because it can ADD to the offset instead of scanning through each byte.

<Scali> anyway, I see that yet another coder is clueless about algos...

Has the oracle spoken here while not knowing how to code the algo either then or now.

<Scali> hutch--: Damnit, I thought you were leet
<Scali> BM does NOT search 650 mb
<Scali> Don't you get it?

This is from a guy who still does not get it.

<Scali> hutch--: If you would understand BM, there would be no need for
benchmarking.
<Scali> it's just SO F*CKING OBVIOUS
<Scali> doh

Apart from the ignorance and the bad manners, here is a man who hold his opinion above objective testing.

Now to dilute you ignorance a little further, a BM algo is no real joy to code in that one stall will kill it stone dead. The advantage of benchmarking is you don't have to listen to bullsh*t, you check the results instead.

I make no apologies for the criticism of the stuff that was around at the time, with the exception of Jeremy Collake's version of Micheal Abrash's BM algo, the rest were slow and it was not opinion, it was benchmarking that demonstrated it.

From memory I was developing on a PIII 4 years ago which did have enough memory to test large sources and most of the code I could find performed very badly. It usually followed from porting poorly designed C algorithms to assembler without understanding Bob Boyer's original design.

The reason why I did the work was to get past the crappy ported C code that was around at the time. The only other BM I saw that performed a bit later was one that Lingo optimised for early pentiums.

I did not then and I do not now take much notice of script kiddies and it is for reasons that are well demonstrated in the old log, a clown with a big mouth who could not deliver, either then or when he issued a challenge some years later.

Regards,

http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-02-20 03:17:30 by hutch--

No, you and your buddy will do. bl0rght was always both very smart and gracious, something that neither of you have managed.

You ignored her attempts to tell you about BM, too.


Try finding short patterns in a few million different strings, something for example that you do in very large log files.

Hrm, parsing a large log file line-by line? I'd rather read the whole chunk into memory (or memory-map-file it) and do a BM or similar, in case I need case-sensitive exact match; otherwise I'd use som regexp probably.


There is nothing smart about using it in the wrong place where it is slower.

Like, duh. It goes without saying that you'll use the right algorithm for the right job.



<Scali> it has way less memory access
<Scali> which is the bottleneck

This is bullsh*t, when a BM is faster, it is because it can ADD to the offset instead of scanning through each byte.

...and thus doing less memory access.



<Scali> hutch--: Damnit, I thought you were leet
<Scali> BM does NOT search 650 mb
<Scali> Don't you get it?

This is from a guy who still does not get it.

Seems like it's you who don't get it? BM wouldn't search through each and every of the 650MB because of the offset shifting.

And obviously you failed to notice any of the other points, as I had expected. Including your failure to comprehend that bl0rght were searching ISO images, not directly from the CD media.

Better luck next time.
Posted on 2004-02-20 07:31:48 by f0dder
/enters thread

Scali == TheSage of CLAX fame?

/quickly exits thread
Posted on 2004-02-20 09:02:40 by ThoughtCriminal
f0dder,

Your attempt to recycle history is about as bad as his and for much the
same reason, lack of technical understanding of the fundamental issues.


Hrm, parsing a large log file line-by line? I'd rather read the whole chunk
into memory (or memory-map-file it) and do a BM or similar, in case I need
case-sensitive exact match; otherwise I'd use som regexp probably.

Your ignorance is showing here, most log files of this type are written
line by line so doing a binary search will not locate the data in relation
to the line, only in relation to the start address.

I have already published the assistance I had available while developing
these algos years ago and again, apart from hot air, bad manners and
ignorant posturing from your friend, the only useful assistance came from
the original author, Bob Boyer.

The log file in fact does demonstrate what he did not know about the design
and mouthing platitudes about it without understanding what it does is
evident from the logs.

As far as my conversations with bl0rght, as neither you or your buddy were
privy to any of them, you are hardly in a position to comment here. I
never did hear any patronising nonsense from bl0rght because she actually
did understand the design.

There is something that both you and your buddy need to learn and that is
for whatever you may be good at, it does not make you good at what you
don't know about. Both of you have this foolish characterisic of shooting
your mouth off then trying to cover it up by abusing the privileges that
are made available to you in a forum like this one.

Harold has put in a lot of work over time to maintain this community yet
you treat both him and his work like a convenience to keep up personal
attacks while disregarding what the members want which is not hearing
either of you propping up your mistakes.

Now as far as my regard for you, it used to be very considerable as I saw
that you learnt things quickly and had very original ideas but over time I
have seen you continue to suck up to this clown like he was some form of
guru and slowly lose your own originality.

You can afford to abandon a clown like this and actually start having a few
ideas of your own again. He may have committed himself to a neurotic ever
closing circle but you actually had more talent than that.

Try to have a little more ambition and not be a lap dog to someone like
this.

Regards,

http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-02-20 19:00:10 by hutch--

Your ignorance is showing here, most log files of this type are written line by line so doing a binary search will not locate the data in relation to the line, only in relation to the start address.

And it would be hard getting a line of text from this start address? Scan back until you hit end of previous line, plus forward until you hit the end of the line with the match. Presto, you have a line you can display. If you want line numbers too, it might be smarter using a hybrid of a non-BM scanner combined with the LF/CRLF/CR (or whatever delimiter) checking (though I guess for logs with "massive size", you wouldn't need linenumbers, as the log entry would have a timestamp or whatever).

And as always, choose the right algorithm for the job, don't limit yourself to a single piece of (optimized or not) code. I can't think of many situations where I could use BM for ascii scanning - while case insensitivity could probably be hacked into BM and still be fast, I would generally need more complex pattern matching rules (think intrusion detection systems, semi-automated log auditing on compromised systems, ...)

Binary search is quite another matter though. For stuff like, say, locating 64kb patterns of data in a 700MB ISO IMAGE, to patch it with correct data before burning the image, I don't know of an algorithm that's nicer than BM. Feel free to show me one, though.


As far as my conversations with bl0rght, as neither you or your buddy were privy to any of them, you are hardly in a position to comment here. I never did hear any patronising nonsense from bl0rght because she actually did understand the design.

I've talked with bl0rght though... and I think it's quite clear the she, scali and vg/jc all knew & were able to implement the algorithm. (and you wouldn't listen to any of them, because you were talking your head off about bruteforce byte scanners). It's not like it's a big deal anyway. I used 16bit asm version of BM in... bum bum, earliest dated source file is 1997, my old hex editor written in pascal. And a few apps that did binary search + patching. Obviously I chose BM because it performed.

As for the context of the log both you and scali have pasted, wasn't if after both scali, vg/jc and bl0rght tried explaining the fundamentals of BM to you, but you still kept on dismissing anything else but your brute-force scanner? I might be wrong though, it's been a couple++ of years, and the major parts might have taken place while I was fooling around with some girl ;)


You can afford to abandon a clown like this and actually start having a few ideas of your own again.

Socially underequipped person, sure. I can deal with that, though (and I hope that he learns some more about social interaction before he's out to get a job). Quite interesting that you get away with all your patronization and reality bending because of your english skills - must be real hard to smother non-native speakers. You should've went into politics btw.

Also, contrary to what you say, the guy can code. But I guess it's just "graphics junk" to you if you don't know anything about the math behind it. Rather cute to see what he got going with a language as slow as java... As for "ideas of my own", I have plenty of them. I don't deal with graphics though, I leave scali at that. Interesting to read about, though.


Try to have a little more ambition and not be a lap dog to someone like this.

Lap dog? So you're a lap dog if you stand up for a friend who's been robbed of his voice? Not that it'd do any good to have him in here, the argument would just degenerate even further.

Try harder. Too easy to take things out of context, highlight bad manners and ignore that scali's actually right about quite a few things... (and silly and anal retentive about other stuff, sure. It's not like I'm trying to glorify the guy.)
Posted on 2004-02-20 21:00:13 by f0dder
You are still off the pace here f0dder, acting like someone elses lap dog is not the way to go. From what I remembered before you started grovelling to his interests and taking up his arguments, you were smarter than he was and a lot more creative.

While I don't see the guy as without talent, he like you tend to extend what you know universally and pontificate on that basis when there are people around who have forgotten more than you know.

You also make the mistake of assuming that wide ranging information is included in your own incestual little circle when as a matter of fact it has always been an enormous market.

Noting that the log shows your buddy as the ignorant pig that he is and this includes the BM algo design, I will again make the point that the research I did was done with the authors help, not f0dder or scali or anyone else and to put it bluntly, a script kiddies with a loud mouth is not a competitor to the authors.

The other aspect of your approach is your willingness to continue second hand fights that you have already lost even though you buddy was banned a number of times in the last few days because of his conduct.

I know Harold is very patient with bad mannered people but your continuation of your buddies follies is just as ill informed and just as bad mannered and it shows a lack of respect for all the work Harold has done to protect and maintain this community.

As I informed your buddy, as long as your arsehole points to the ground, you will never win an argument with me because you start from the wrong basis. I have made more mistakes than you will make in a lifetime and over a lifetime I have the help of many very talented people but none of them ever tried the posturing and bullsh*t that comes out of you and your buddy.

To make the point here, none of them were runny nosed little sh*ts with an ego problem trying to make a name for themselves in the absence of talent.

Regards,

http://www.asmcommunity.net/board/cryptmail.php?tauntspiders=in.your.face@nomail.for.you&id=2f46ed9f24413347f14439b64bdc03fd
Posted on 2004-02-21 00:39:49 by hutch--
Afternoon, All.

That's about as far as this thread will go.
Hope you enjoyed the show.

Cheers,
Scronty
Posted on 2004-02-21 04:28:58 by Scronty