A general request for information regarding Dustin Cook

[4Q]

4Q wrote:
> Dustin Cook wrote:
> > On Feb 23, 11:44 pm, "4Q"

*fixup* for the archive

<quote> childish bASIC

randomize
a=rnd(0)
a=a mod 1
b=rnd(0)
b=b mod 23
death=b
b=rnd(0)
b=b mod 23
runy=b
b=rnd(0)
b=b mod 23

if death=runy then
a=rnd(0)
a=a mod 23
runy=a
endif
ent$=chr$(13)
print"Viral Anticipation... Here is a chance for you to run the
program!"
print"special greetings to Nick Fitzgerald (**** you!) and Graham
Cluley"
print"of Sophos (www.sophos.com); You ****in lardass."
print""
print"Use your arrows (left & right) to select a square below."
print"One of the squares has been set to allow your program"
print"to continue running, While another will destroy your file."
print"And the remaining ones? They do nothing. Make your decision."
print"Press <enter> to record it. Good-Luck <Evil Grin>"
print""
print"UA:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A :A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:?"
print"^3 Are you of a gambling nature? Muaha ^3"
print"AA:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A :A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:U"
for y=1 to 24
a$=a$+"+-"
next y
print a$;
zone=csrlin
rem setup where the key door and bombs are, There are only 4 bombs
rem to make the game not impossible.
rem K is left, M is right

local=b
locate zone,local
print"U";
while exitflag=0
a$=inkey$
if a$="K" then
if local=0 then
beep
else
gosub check:
local=local-1
locate zone,local
print"U";
endif
endif
if a$="M" then
if local=23 then
beep
else
gosub check:
local=local+1
locate zone,local
print"U";
endif
endif
if a$=ent$ then
exitflag=1
ar=local
endif
gosub die_cursor:
wend
print"th"
print""
print"A choice has been made... So what shall become of the program?"
print""
print"Will the program continue running? ";
if ar<> runy then
print"hah, Nope."
print"has the program been lost to the depths of electronic noise? "
if ar=death then
print"Hah, Yes Cluley's lardass squished it flat. "
else
print"Nope. The file moved out of the way as the lardass fell."
endif
else
print"Why yes... yes it will."
endif
end

check:
for x=0 to 22
locate zone,local
print"+-";
next x
return

die_cursor:
rem off with the damn cursor
REM turn crsr off by positioning off screen
REM ASIC leaves it on for some reaosn ALL the time!
AX=&HEX0200
BX=0
DX=25*256
INT86 (&HEX10,AX,BX,NA,DX,NA,NA,NA,NA,NA)
return

</quote> childish code. No wonder they
call it BASIC (read: code for children)


4Q
http://fourq.host.sk/INFO/

[Kadaitcha Man]

4Q <paul_zest@hushmail.com> Thou incompetent tardy son. Thou putrid
notorious-bawd. Thou despicable anointed sovereign of sighs and groans.
Thou musty mannish coward. Ye nagged and ye squawked:

> 4Q wrote:
>> Dustin Cook wrote:
>>> On Feb 23, 11:44 pm, "4Q"
>
> *fixup* for the archive
>
> <quote> childish bASIC
>
> randomize
> a=rnd(0)
> a=a mod 1
> b=rnd(0)
> b=b mod 23
> death=b
> b=rnd(0)
> b=b mod 23
> runy=b
> b=rnd(0)
> b=b mod 23
>
> if death=runy then
> a=rnd(0)
> a=a mod 23
> runy=a
> endif
> ent$=chr$(13)
> print"Viral Anticipation... Here is a chance for you to run the
> program!"
> print"special greetings to Nick Fitzgerald (**** you!) and Graham
> Cluley"
> print"of Sophos (www.sophos.com); You ****in lardass."
> print""
> print"Use your arrows (left & right) to select a square below."
> print"One of the squares has been set to allow your program"
> print"to continue running, While another will destroy your file."
> print"And the remaining ones? They do nothing. Make your decision."
> print"Press <enter> to record it. Good-Luck <Evil Grin>"
> print""
> print"UA:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A :A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:?"
> print"^3 Are you of a gambling nature? Muaha ^3"
> print"AA:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A :A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:A:U"
> for y=1 to 24
> a$=a$+"+-"
> next y
> print a$;
> zone=csrlin
> rem setup where the key door and bombs are, There are only 4 bombs
> rem to make the game not impossible.
> rem K is left, M is right
>
> local=b
> locate zone,local
> print"U";
> while exitflag=0
> a$=inkey$
> if a$="K" then
> if local=0 then
> beep
> else
> gosub check:
> local=local-1
> locate zone,local
> print"U";
> endif
> endif
> if a$="M" then
> if local=23 then
> beep
> else
> gosub check:
> local=local+1
> locate zone,local
> print"U";
> endif
> endif
> if a$=ent$ then
> exitflag=1
> ar=local
> endif
> gosub die_cursor:
> wend
> print"th"
> print""
> print"A choice has been made... So what shall become of the program?"
> print""
> print"Will the program continue running? ";
> if ar<> runy then
> print"hah, Nope."
> print"has the program been lost to the depths of electronic noise? "
> if ar=death then
> print"Hah, Yes Cluley's lardass squished it flat. "
> else
> print"Nope. The file moved out of the way as the lardass fell."
> endif
> else
> print"Why yes... yes it will."
> endif
> end
>
> check:
> for x=0 to 22
> locate zone,local
> print"+-";
> next x
> return
>
> die_cursor:
> rem off with the damn cursor
> REM turn crsr off by positioning off screen
> REM ASIC leaves it on for some reaosn ALL the time!
> AX=&HEX0200
> BX=0
> DX=25*256
> INT86 (&HEX10,AX,BX,NA,DX,NA,NA,NA,NA,NA)
> return
>
> </quote> childish code. No wonder they
> call it BASIC (read: code for children)

These days, with .NET there is no fundamental difference between BASIC, C#
and J#, et al. Real differences lie only in how the code is required to be
structured by the precompiler. Only a very short copy/paste manoeuvre is
needed to convert .NET-based C# to Visual Basic or Visual Java, and back
again.

Anyway, that aside, I have often witnessed Dustfart bragging about his "1337
skillz" in coding. I almost had a fit from laughing at the tripe up there.
If he were an employee of mine and showed as much unworthy pride in his awful
scribblings as he has displayed on usenet, I'd fire his ****ing arse, on the
spot, and no two ways about it. I've seen better scribblings in Indonesia;
made with daubed faeces by captive orang-utans bored ****less from nothing
else to do except swing in the trees and eat an endless supply of bananas.

"That's a simple programming thing tho"
http://groups.google.com.au/group/al...e=source&hl=en

The emphasis is on simple.

"I do all kinds of programming. I'm not the ignorant pissant you wish I was.
and your fixing to learn that, albeit the hard way."
http://groups.google.com.au/group/24...e=source&hl=en

Looks like a disguised k0oKTHREAT to me, that does. Ah... here is one of the
many Dustfart k0oKTHREATS that never happened:

"You foolishly imagine that I don't maintain contact with my former
associates. You really should do yourself a favor before you get
yourself involved in something that has reach far beyond usenet and
your little auk home. DDoSing is a very real and very harmful sport
some of my comrades are still into, only they do it with thousands of
zombie computers. Thousands son. "

And in the very same post...

"One final comment, "Pity the fool who doesn't understand programming.""

http://groups.google.com.au/group/al...e=source&hl=en

That last one cracked me up. I could hardly breathe from laughing at him.

So, on to a really rough and quick but professional critique of the code
above... I was a professional software developer, now in management, though
I still cut a lot of code just to keep up with the latest advancements...

> randomize
> a=rnd(0)
> a=a mod 1
> b=rnd(0)
> b=b mod 23
> death=b
^^^^^^^^^^
> b=rnd(0)
> b=b mod 23
> runy=b
> b=rnd(0)
> b=b mod 23

The variable named "death" indicates that the language is capable of
supporting variable names other than simple a, b, c. Code should make use of
extended variable names with the intent of increasing the code's ability to
self-document.

As another example of the woefully poor exploitation of variable names...

> ar=local

ar might be short for "AR AR ME 'ARTIES!!!"

Perhaps Dustfart fancies himself as a pirate on the high seas or something.

> b=rnd(0)
> b=b mod 23
> death=b

Three lines of code are used to do what can be done in one line...

death = rnd(0) mod 23

The results are the same but the process is not. Dustfart's amateurish and
woefully inefficient code requires values to be moved left, right and
centre, then all the way back again before a result is obtained. I use the
word "amateurish" reservedly. I am bereft of sufficient one-word
superlatives to convey the idea of complete rubbish born of his artless
bumbling.

> gosub check:

Subroutines should only be used where there is a need to eliminate repeated
_larger_ segments of code. The subroutine named "check" is called from only
two places in the entire ...ahem... "program", and it will cause the
compiler/run environment to beat on the processor; see a little later about
strings. Given what I say a later about strings inside loops, the "check"
subroutine is not just entirely superfluous, it is detrimental to the
efficient execution of the code.

> b=b mod 23
> death=b
> b=rnd(0)
> b=b mod 23
> runy=b
> b=rnd(0)
> b=b mod 23
>
> if death=runy then
> a=rnd(0)
> a=a mod 23

Some variable modulus 23 is used 4 times in 10 lines. Setting aside that the
code segments use 3 lines where one line will do, the whole rnd(x) mod 23
should have been a candidate for conversion into a subroutine, then
discarded as a candidate because it would probably require just as many
processor cycles to jump and return as it would to calculate the modulus of
two simple numbers inline. I doubt Dustfart's capacity to have ever
considered that at all. I suppose soon enough we'll see if his hindsight
is operating at a perfect 20-20.

> for y=1 to 24
> a$=a$+"+-"
> next y

The code is very badly written and grossly inefficient. Any programmer worth
the designation of "programmer" should know that strings are, more often
than not, immutable in BASIC, which means that once a value has been
assigned a string variable the value cannot be extended without moving the
original to a new place, destroying the original variable then moving the
new value from its temporary place and into a newly reserved block in
memory.

In the loop above, the compiler (I assume compiler, surely he's not daft
enough to use interpreted BASIC. Is he?), is forced to move the contents of
the variable into a transient location, free up the formerly reserved memory
location, create a new reserved location, then move the contents from
transient storage to the new location no less than 24 times in a row. Each
of the twenty four executions are repeated for every time the code loops
through the controlling while/wend construct. It is utter ****e; it is not
code.

It would have been far more efficient to simply declare a variable with...

SomeVar$ = "+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..."

But I suppose that would deny Dustfart the bragging rights on knowing how to
execute a simple For...Next loop.

> if a$="K" then
> ...
> endif

Still on the subject of sloppy, inneficient coding; at compile time, the
compiler will not be able to work out how or where to allocate a home for
the simple "K" string literal. The job will therefore be left to runtime,
where, of course, execution will be slowed while the run environment works
out what to do with it. A far more efficient and elegant method would be...

SomeVar$ = "K"
...
...
If SomeOtherVar$ = SomeVar$ Then
...
EndIf

In fact...

If NOT ((SomeOtherVar$ <> SomeVar$) AND (SomeOtherVar$ <> YetAnotherVar$))
Then
...
EndIf

...would be just as quick as, if not actually quicker than, the mess
Dustfart made; the correct word is wrote but his crap is not worthy of such
a word. A not equal operation requires less processor cycles than an equal
operation. With a properly structured If...Then clause, there would be no
need for the dog's breakfast below:

> if a$="K" then
> if local=0 then
> beep
> else
> gosub check:
> local=local-1
> locate zone,local
> print"U";
> endif
> endif
> if a$="M" then
> if local=23 then
> beep
> else
> gosub check:
> local=local+1
> locate zone,local

As an alternative to checking "if a$="K" then", to avoid ****ing about with
literals entirely...

If SomeOtherVar$ = Chr$(70) Then
...
EndIf

There is no sign in the code whatsoever that Dustfart knows what Boolean
notation is or does in BASIC. I may have been inclined to be a little less
critical had I seen something, anything, along the lines of...

If -1 * ((a$ <> k$) + (a$ <> m$)) Then
...
EndIf

Alas, there's nothing. No sign of Boolean notation in a chunk of crap
that cries out for it.

> if a$="K" then
> if local=0 then
> beep
> else
> gosub check:
> local=local-1
> locate zone,local
> print"U";
> endif
> endif

Horrible, horrible, horrible. Bloody horrible. Unreadable tripe is what
Dustfart has created. It can not reasonably be labelled "code".

If X Then
If Y Then
...
Else
...
EndIf
EndIf

> wend

You need at least four pairs of eyes to find the controlling while
statement.

> die_cursor:
> rem off with the damn cursor
> REM turn crsr off by positioning off screen
> REM ASIC leaves it on for some reaosn ALL the time!
> AX=&HEX0200
> BX=0
> DX=25*256
> INT86 (&HEX10,AX,BX,NA,DX,NA,NA,NA,NA,NA)
> return

It's supposedly a payload for a virus, so who the **** cares if the cursor
is on or off? What was he doing here? Bragging that he knows how to call
int86? Why the **** would he bother with int86 video routines? Why isn't
he showing off his 1337 skillz and calling int13 to make the low-level
disk services sing and dance?

> 4Q
> http://fourq.host.sk/INFO/

"Pity the fool who doesn't understand programming."

The conclusion is ironic... the fool doesn't understand programming.

Two things in closing...

1. I typed this into google...

'REM turn crsr off by positioning off screen"

I wanted to see if there were any other sources for the exact same string of
text. As you can see, the opening quote is a single not a double quote, a
typo on my part. The typo caused results to be found and the first link that
came up showed this...

Touring the Commodore 128 Keyboard10 PRINT CHR$(147):REM CLEAR SCREEN 20
CHAR,14,11,"OFF THE TOP" 30 CHAR,12,12 ... Turn on your C-128, hold down the
CONTROL key, and press G. Surprise!

Coming up with that result in top place from a line in Dustfart's code is an
insult to to the VIC-20, let alone the Commodore 128. Primary school children
write better code than Dustfart.

2. Please feel free to use this quick review on your website. Source
credited, please. I'd be happy to have my name alongside some text that rips
apart the atrocious mess he makes and has the unmitigated cheek to call
"code".

Oh, as an addendum, I've rewritten Dustfart's virus payload in pseudocode...

Do some fancy bull**** with modulus to make me look reely, reely good
In amongst all the fnacy bull****, pick a number, any number
Print some ****witted, geeky message on the screen
Force the user to pick a key
If the user picked this key and I picked a certain number then
Call a subroutine to spray some **** on the screen
Call a reely 1337 DOS interrupt a few times to make me look reely k00l
Print another ****witted, geeky message on the screen
Don't do anything else, just exit
End if
If the user picked that key and I picked a different number then
Call a subroutine to spray some **** on the screen
Call a reely 1337 DOS interrupt a few times to make me look reely k00l
Print another ****witted, geeky message on the screen
Don't do anything else, just exit
End if

If you look at the code closely, that is exactly what it does.

print"th"
print""
print"A choice has been made... So what shall become of the program?"
print""
print"Will the program continue running? ";
if ar<> runy then
print"hah, Nope."
print"has the program been lost to the depths of electronic noise? "
if ar=death then
print"Hah, Yes Cluley's lardass squished it flat. "
else
print"Nope. The file moved out of the way as the lardass fell."
endif
else
print"Why yes... yes it will."
endif
end
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ BWAHAHAHAHAHAHAHAH! LMAO

<snort>

****ing "virus writer" my arse.

--
alt.usenet.kooks - Pierre Salinger Memorial Hook, Line & Sinker:
September 2005, April 2006, January 2007.

"Now I know what it is. Now I know what it means when an
alt.usenet.kook x-post shows up."
AOK in news:ermdlu$nli$1@registered.motzarella.org

[Dustin Cook]

On Feb 25, 12:11 am, "Kadaitcha Man" <nntp.n...@gmail.com> wrote:
> > </quote> childish code. No wonder they
> > call it BASIC (read: code for children)

Actually, it's not quiet basic.. See below, as I tear K-man to
shreds

> These days, with .NET there is no fundamental difference between BASIC, C#
> and J#, et al. Real differences lie only in how the code is required to be
> structured by the precompiler. Only a very short copy/paste manoeuvre is
> needed to convert .NET-based C# to Visual Basic or Visual Java, and back
> again.

blah blah. Any developer realizes this.. even you... shrug.
> made with daubed faeces by captive orang-utans bored ****less from nothing
> else to do except swing in the trees and eat an endless supply of bananas.
>
> "That's a simple programming thing tho"http://groups.google.com.au/group/alt.comp.os.windows-xp/msg/616184df...
>
> The emphasis is on simple.

So simple in fact, you missed it.. See below.
> So, on to a really rough and quick but professional critique of the code
> above... I was a professional software developer, now in management, though
> I still cut a lot of code just to keep up with the latest advancements...
>
>
>
> > randomize
> > a=rnd(0)
> > a=a mod 1
> > b=rnd(0)
> > b=b mod 23
> > death=b
> ^^^^^^^^^^
> > b=rnd(0)
> > b=b mod 23
> > runy=b
> > b=rnd(0)
> > b=b mod 23
>
> The variable named "death" indicates that the language is capable of
> supporting variable names other than simple a, b, c. Code should make useof
> extended variable names with the intent of increasing the code's ability to
> self-document.

True, that was sloppy on my part. I think I said the code was sloppy
originally tho..

> As another example of the woefully poor exploitation of variable names...
>
> > ar=local
>
> ar might be short for "AR AR ME 'ARTIES!!!"
>
> Perhaps Dustfart fancies himself as a pirate on the high seas or something.

just lazy...

> > b=rnd(0)
> > b=b mod 23
> > death=b
>
> Three lines of code are used to do what can be done in one line...
>
> death = rnd(0) mod 23

Ahh, but your wrong sir. This is Asic, it cannot be done in one
line.

> The results are the same but the process is not. Dustfart's amateurish and

The results would be the same, If the language supported it in one
statement like that. (It doesn't). It's asic, not quiet basic.

> woefully inefficient code requires values to be moved left, right and
> centre, then all the way back again before a result is obtained. I use the

Ouch, I don't think you realize how close asic really is to
assembler... Your loss.

> word "amateurish" reservedly. I am bereft of sufficient one-word
> superlatives to convey the idea of complete rubbish born of his artless
> bumbling.
>
> > gosub check:
>
> Subroutines should only be used where there is a need to eliminate repeated
> _larger_ segments of code. The subroutine named "check" is called from only
> two places in the entire ...ahem... "program", and it will cause the
> compiler/run environment to beat on the processor; see a little later about

Actually, it won't. The assembler code is referenced via jmp
statements in the executable. It saves codespace, by writing code once
if it's going to be used more than once, it should be a routine. Why
repeat the same code?

> strings. Given what I say a later about strings inside loops, the "check"
> subroutine is not just entirely superfluous, it is detrimental to the
> efficient execution of the code.

Ehhhehh.. Heh, the code is written in asic. I don't think you quiet
understand what asic is.

> > b=b mod 23
> > death=b
> > b=rnd(0)
> > b=b mod 23
> > runy=b
> > b=rnd(0)
> > b=b mod 23
>
> > if death=runy then
> > a=rnd(0)
> > a=a mod 23
>
> Some variable modulus 23 is used 4 times in 10 lines. Setting aside that the
> code segments use 3 lines where one line will do, the whole rnd(x) mod 23
> should have been a candidate for conversion into a subroutine, then
> discarded as a candidate because it would probably require just as many
> processor cycles to jump and return as it would to calculate the modulus of
> two simple numbers inline. I doubt Dustfart's capacity to have ever
> considered that at all. I suppose soon enough we'll see if his hindsight
> is operating at a perfect 20-20.

Pure lazyness on my part. The entire rnd code could have been
converted to a subroutine, but it has to occur in that order. Asic
doesn't understand multiple statements/actions per line.

> > for y=1 to 24
> > a$=a$+"+-"
> > next y
>
> The code is very badly written and grossly inefficient. Any programmer worth
> the designation of "programmer" should know that strings are, more often
> than not, immutable in BASIC, which means that once a value has been
> assigned a string variable the value cannot be extended without moving the
> original to a new place, destroying the original variable then moving the
> new value from its temporary place and into a newly reserved block in
> memory.

You don't actually do much with assembler do you? Well anyways, when
asic compiles the binary, the resulting assembler code assigns
80characters of memory for each string variable I use. Regardless of
whether or not I use all of the space, the location of the variable is
known the whole time my code is running. Nothing need be, moved.
Overwritten as you wish, but moved, not unless you want too. If you
don't like this design, you may wish to take it up with Asics author,
I'm unable to evade this limitation myself.

> In the loop above, the compiler (I assume compiler, surely he's not
daft
> enough to use interpreted BASIC. Is he?), is forced to move the contents of
> the variable into a transient location, free up the formerly reserved memory
> location, create a new reserved location, then move the contents from
> transient storage to the new location no less than 24 times in a row. Each
> of the twenty four executions are repeated for every time the code loops
> through the controlling while/wend construct. It is utter ****e; it is not
> code.

Nope, Nope, Nope Nope, I have more of those. That's not what's
occuring in the resulting assembler binaries generated by the
compiler. If it was a real HLL language, it might do that, but it
doesn't have such capabilities.

STORAGE FORMATS

NORMAL INTEGERS are stored in ASIC as two bytes, with the low
order byte
appearing first (as per Intel conventions).

LONG INTEGERS are stored in ASIC as four bytes, with the least
significant
word first, followed by the most significant word. Within these
two words,
the least significant byte appears first followed by the most
significant
byte.

Page - 140




STRING VARIABLES are stored as FIXED 80 character strings
terminated by an
ASCII null character for a total length of 81 characters.

STRING CONSTANTS are stored with 1 byte per character in the
string
followed by a terminating ASCII null character.

DECIMAL VARIABLES AND CONSTANTS are stored in 8 bytes, from least
significant byte to most significant byte. They are stored as
signed
binary integers, with an implicit decimal point. The integer
values are
adjusted after each multiplication or division to scale the
result to the
proper number of decimal places.

ARRAYS - Each element in an array requires two bytes. (Don't
forget arrays
have an element zero (i.e. DIM A(2) is comprised of A(0), A(1),
and A(2)).

Examples:

Item Data Type Storage Requirements
A Integer Variable 2 bytes
17 Integer Constant 2 bytes
A& Long Integer Variable 4 bytes
55555& Long Integer Constant 4 bytes
A$ String Variable 81 bytes
"ABC" String Constant 4 bytes
"A" String Constant 2 bytes
A@ Decimal Variable 8 bytes
1.23456 Decimal Constant 8 bytes
12345@ Decimal Constant 8 bytes
DIM A(10) Integer Array 22 bytes
DIM A(1) Integer Array 4 bytes
DIM A&(10) Long Int Array 44 bytes
DIM A$(10) String Array 891 bytes
DIM A@(10) Decimal Array 88 bytes

As you can see, string variables are expensive in terms of
storage space.
Since string constants are stored at actual length +1, It is MUCH
more
efficient to store short strings as constants in ASIC in terms of
storage
space. There is no performance advantage to constants over
variables,
however.

In disk files, strings, decimals, and integers are written out in
the above
formats. Note that unlike GWBASIC/BASICA, integer and decimal
values are
NOT expanded into strings when written, and conversely, not
converted from
strings when read. String variables and constants are written
out as ASCII
strings terminated by a null character (however, the null can be
suppressed). Thus, string variables when written to disk, take
the same
space byte for byte as string constants.

The reason behind fixed length string variables was avoidance of
string
"garbage collection". In addition to slight performance
advantages, there
is the added benefit of providing a string memory address which
never


Page - 141



changes. Thus once VARPTR retrieves the address of a variable,
you never
have to worry about it changing.
EXE File Memory Map

The following describes the structure of the ".EXE" file created
by ASIC.
In the COM file format the code, data, and stack are all in the
same memory
segment. In an ASIC EXE format file, the code, data, and stack
each reside
in their own segment. Addresses are given as offsets from the CS
(Code
Segment), DS (Data Segment), or SS (Stack Segment) registers.


Description Address Range
------------------------------ -------------
Program Segment Prefix (PSP) CS: minus 00FF
(Created/Required by DOS, and
immediately precedes the
code segment)
|
|
v
Code Segment (CS
User Program 0000 +
|
|
v
System Subroutines Address Varies
|
|
v
Data Segment (DS
Program Data Area #1 0000 - 0102
String Conversion Buffer 0103 - 0109
Input Buffer 010A - 015B
Screen Width 015C
Color/Attribute Byte 015D
Screen Graphics Mode 015E
Cursor Position 015F - 0160
File Control Table 0161 - 0169
ERROR System Variable 016A - 016B
System Subroutine Vectors 016C - 017F
EXTENDED System Variable 0180 - 0181
RND Seed 0182 - 0185
Math Work Area 0186 - 018D
DEFSEG System Variable 018E - 018F
Start DATA Block Pointer 0190 - 0191
Current DATA Block Pointer 0192 - 0193
Reserved for future use 0194 - 0195
Optional System Sub Vectors 0196+
and Work Areas (decimal math option)
Program Data Area #2 Address Varies
|
|
v
Stack (SS (builds downward) 0000 - 07D0 (0FA0--debug
mode)


Page - 144



NOTE: The format of an EXE file created using the
"B/OBJ" option is essentially the same as the one
produced by the "B/EXE" option, except that the "B/OBJ"
output file may contain additional code or data
segments linked in from other OBJ or LIB files

Read it
0wned k-man. Full documentation for asic as well as the compiler can
be found on my site, if your inclined enough to educate yourself.
follow this link:
http://bughunter.it-mate.co.uk/asic500.zip
and if you dont want to touch the problem, but want to see the docs
alone, go here:
http://bughunter.it-mate.co.uk/asic.txt

There ya go, enjoy!



> It would have been far more efficient to simply declare a variable with...
>
> SomeVar$ = "+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-..."
>
> But I suppose that would deny Dustfart the bragging rights on knowing howto
> execute a simple For...Next loop.
>
> > if a$="K" then
> > ...
> > endif
>
> Still on the subject of sloppy, inneficient coding; at compile time, the
> compiler will not be able to work out how or where to allocate a home for
> the simple "K" string literal. The job will therefore be left to runtime,
> where, of course, execution will be slowed while the run environment works
> out what to do with it. A far more efficient and elegant method would be....
>
> SomeVar$ = "K"
> ...
> ...
> If SomeOtherVar$ = SomeVar$ Then
> ...
> EndIf
>
> In fact...
>
> If NOT ((SomeOtherVar$ <> SomeVar$) AND (SomeOtherVar$ <> YetAnotherVar$))
> Then
> ...
> EndIf
>
> ...would be just as quick as, if not actually quicker than, the mess
> Dustfart made; the correct word is wrote but his crap is not worthy of such
> a word. A not equal operation requires less processor cycles than an equal
> operation. With a properly structured If...Then clause, there would be no
> need for the dog's breakfast below:
>
>
>
> > if a$="K" then
> > if local=0 then
> > beep
> > else
> > gosub check:
> > local=local-1
> > locate zone,local
> > print"U";
> > endif
> > endif
> > if a$="M" then
> > if local=23 then
> > beep
> > else
> > gosub check:
> > local=local+1
> > locate zone,local
>
> As an alternative to checking "if a$="K" then", to avoid ****ing about with
> literals entirely...
>
> If SomeOtherVar$ = Chr$(70) Then
> ...
> EndIf
>
> There is no sign in the code whatsoever that Dustfart knows what Boolean
> notation is or does in BASIC. I may have been inclined to be a little ...
>
> read more »

[Dustin Cook]

On Feb 25, 1:18 am, "Dustin Cook" <bughunter.dus...@gmail.com> wrote:
> On Feb 25, 12:11 am, "Kadaitcha Man" <nntp.n...@gmail.com> wrote:
>
> > > </quote> childish code. No wonder they
> > > call it BASIC (read: code for children)
>
> Actually, it's not quiet basic.. See below, as I tear K-man to
> shreds
>
> > These days, with .NET there is no fundamental difference between BASIC, C#
> > and J#, et al. Real differences lie only in how the code is required to be
> > structured by the precompiler. Only a very short copy/paste manoeuvre is
> > needed to convert .NET-based C# to Visual Basic or Visual Java, and back
> > again.
>
> blah blah. Any developer realizes this.. even you... shrug.
>
> > made with daubed faeces by captive orang-utans bored ****less from nothing
> > else to do except swing in the trees and eat an endless supply of bananas.
>
> > "That's a simple programming thing tho"http://groups.google.com.au/group/alt.comp.os.windows-xp/msg/616184df...
>
> > The emphasis is on simple.
>
> So simple in fact, you missed it.. See below.
>
>
>
> > So, on to a really rough and quick but professional critique of the code
> > above... I was a professional software developer, now in management, though
> > I still cut a lot of code just to keep up with the latest advancements...
>
> > > randomize
> > > a=rnd(0)
> > > a=a mod 1
> > > b=rnd(0)
> > > b=b mod 23
> > > death=b
> > ^^^^^^^^^^
> > > b=rnd(0)
> > > b=b mod 23
> > > runy=b
> > > b=rnd(0)
> > > b=b mod 23
>
> > The variable named "death" indicates that the language is capable of
> > supporting variable names other than simple a, b, c. Code should make use of
> > extended variable names with the intent of increasing the code's ability to
> > self-document.
>
> True, that was sloppy on my part. I think I said the code was sloppy
> originally tho..
>
> > As another example of the woefully poor exploitation of variable names...
>
> > > ar=local
>
> > ar might be short for "AR AR ME 'ARTIES!!!"
>
> > Perhaps Dustfart fancies himself as a pirate on the high seas or something.
>
> just lazy...
>
> > > b=rnd(0)
> > > b=b mod 23
> > > death=b
>
> > Three lines of code are used to do what can be done in one line...
>
> > death = rnd(0) mod 23
>
> Ahh, but your wrong sir. This is Asic, it cannot be done in one
> line.
>
> > The results are the same but the process is not. Dustfart's amateurish and
>
> The results would be the same, If the language supported it in one
> statement like that. (It doesn't). It's asic, not quiet basic.
>
> > woefully inefficient code requires values to be moved left, right and
> > centre, then all the way back again before a result is obtained. I use the
>
> Ouch, I don't think you realize how close asic really is to
> assembler... Your loss.
>
> > word "amateurish" reservedly. I am bereft of sufficient one-word
> > superlatives to convey the idea of complete rubbish born of his artless
> > bumbling.
>
> > > gosub check:
>
> > Subroutines should only be used where there is a need to eliminate repeated
> > _larger_ segments of code. The subroutine named "check" is called from only
> > two places in the entire ...ahem... "program", and it will cause the
> > compiler/run environment to beat on the processor; see a little later about
>
> Actually, it won't. The assembler code is referenced via jmp
> statements in the executable. It saves codespace, by writing code once
> if it's going to be used more than once, it should be a routine. Why
> repeat the same code?
>
> > strings. Given what I say a later about strings inside loops, the "check"
> > subroutine is not just entirely superfluous, it is detrimental to the
> > efficient execution of the code.
>
> Ehhhehh.. Heh, the code is written in asic. I don't think you quiet
> understand what asic is.
>
>
>
> > > b=b mod 23
> > > death=b
> > > b=rnd(0)
> > > b=b mod 23
> > > runy=b
> > > b=rnd(0)
> > > b=b mod 23
>
> > > if death=runy then
> > > a=rnd(0)
> > > a=a mod 23
>
> > Some variable modulus 23 is used 4 times in 10 lines. Setting aside that the
> > code segments use 3 lines where one line will do, the whole rnd(x) mod 23
> > should have been a candidate for conversion into a subroutine, then
> > discarded as a candidate because it would probably require just as many
> > processor cycles to jump and return as it would to calculate the modulus of
> > two simple numbers inline. I doubt Dustfart's capacity to have ever
> > considered that at all. I suppose soon enough we'll see if his hindsight
> > is operating at a perfect 20-20.
>
> Pure lazyness on my part. The entire rnd code could have been
> converted to a subroutine, but it has to occur in that order. Asic
> doesn't understand multiple statements/actions per line.
>
> > > for y=1 to 24
> > > a$=a$+"+-"
> > > next y

I'd like to show you a couple of other ways of doing the same
thing.

a$=string$(24,"+-")

that will do the same as the code above and below.

a$="+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-"

another way

a$="**** k-man"
kmanshouse=varptr(a$)
ourhouse=defseg(0)
x=1
y=kmanshouse
while x<25
poke y,27
x=x+1
y=y+1
wend

and another

a$="**** k-man"
kmanshouse=varptr(a$)
ourhouse=defseg(0)
x=kmanshouse
y=x+24
for z=x to y
poke z,27
next z

the end result is the same, but the code generated isn't. Now, you
wouldn't understand why this would be considered useful to someone
like me, but I suspect 4Q might get the idea behind it. This is how
things are done in Asic k-man, 4Q has mislead you concerning what asic
is and isn't.

--
Dustin Cook
http://bughunter.it-mate.co.uk

[Kadaitcha Man]

Dustin Cook <bughunter.dustin@gmail.com> Thou such toasts-and-butter.
Out of my sight, thou dost infect mine eyes. Thou idle gaud. Thou
hell-bound. Ye blurted and ye blubbed:

> a$=string$(24,"+-")

Here, eat some crow, you piteous halfwit...

> that will do the same as the code above and below.
>
> a$="+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-"

Pig's ****ing arse it will, you utterly inept wretch.

STRING$ only recognises the first character, so, unlike in your delusional
world where any ****ing old bull**** rules, in the real world, the result of
this:

a$=string$(24,"+-")

Is this...

"++++++++++++++++++++++++"

BWAHAHAHAHAHAHAHAHAHA! LMFARO@you, Dustfart.

So, you still reckon you're a programmer, eh, Dustfart? **** me dead. You
waffle on and on about assembler [sic] code and you can't even ****ing well
write working code in your precious ****BASIC. BWAHAHAHAHAHAHA! ****ing
pathetic.

--
alt.usenet.kooks - Pierre Salinger Memorial Hook, Line & Sinker:
September 2005, April 2006, January 2007.

"Now I know what it is. Now I know what it means when an
alt.usenet.kook x-post shows up."
AOK in news:ermdlu$nli$1@registered.motzarella.org

[bughunter.dustin@gmail.com]

On Feb 25, 7:05 am, "Kadaitcha Man" <nntp.n...@gmail.com> wrote:
> Dustin Cook <bughunter.dus...@gmail.com> Thou such toasts-and-butter.
> Out of my sight, thou dost infect mine eyes. Thou idle gaud. Thou
> hell-bound. Ye blurted and ye blubbed:
>
> > a$=string$(24,"+-")
>
> Here, eat some crow, you piteous halfwit...
>
> > that will do the same as the code above and below.
>
> > a$="+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-"
>
> Pig's ****ing arse it will, you utterly inept wretch.
>
> STRING$ only recognises the first character, so, unlike in your delusional
> world where any ****ing old bull**** rules, in the real world, the result of
> this:
>
> a$=string$(24,"+-")
>
> Is this...
>
> "++++++++++++++++++++++++"
>
> BWAHAHAHAHAHAHAHAHAHA! LMFARO@you, Dustfart.

Yep, so you read the asic.txt link eh? It's been a very long time
since I've used the function.
language syntax helps, doesn't it?

> So, you still reckon you're a programmer, eh, Dustfart? **** me dead. You

Yep, I am. I know to atleast know the language syntax before I comment
on someone elses code, especially if I'm trying to make them look
stupid in doing so, wouldn't want it to backfire as it has here on
you.

> waffle on and on about assembler [sic] code and you can't even ****ing well
> write working code in your precious ****BASIC. BWAHAHAHAHAHAHA! ****ing
> pathetic.

Well k-man, I made a simple mistake which would have still generated
an executable. Your one line code improvement over my code that you
dedicated a paragraph bashing on me was not proper syntax, and would
not compile.

My programming mistake resulting in a less functional program, yours
resulted in no functional program at all. <g>


> --
> alt.usenet.kooks - Pierre Salinger Memorial Hook, Line & Sinker:
> September 2005, April 2006, January 2007.
>
> "Now I know what it is. Now I know what it means when an
> alt.usenet.kook x-post shows up."
> AOK innews:ermdlu$nli$1@registered.motzarella.org

[Kadaitcha Man]

bughunter.dustin@gmail.com Thou votary to fond desire. Thou heedless
jolthead. Thou poor inch of nature. Bless me, what a fry of fornication
is at the door. Ye meandered and ye ministered:

> On Feb 25, 7:05 am, "Kadaitcha Man" <nntp.n...@gmail.com> wrote:
>> Dustin Cook <bughunter.dus...@gmail.com> Thou such toasts-and-butter.
>> Out of my sight, thou dost infect mine eyes. Thou idle gaud. Thou
>> hell-bound. Ye blurted and ye blubbed:
>>
>>> a$=string$(24,"+-")
>>
>> Here, eat some crow, you piteous halfwit...
>>
>>> that will do the same as the code above and below.
>>
>>> a$="+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-"
>>
>> Pig's ****ing arse it will, you utterly inept wretch.
>>
>> STRING$ only recognises the first character, so, unlike in your
>> delusional world where any ****ing old bull**** rules, in the real
>> world, the result of this:
>>
>> a$=string$(24,"+-")
>>
>> Is this...
>>
>> "++++++++++++++++++++++++"
>>
>> BWAHAHAHAHAHAHAHAHAHA! LMFARO@you, Dustfart.
>
> Yep, so you read the asic.txt link eh? It's been a very long time
> since I've used the function.
> language syntax helps, doesn't it?

You need to backpedal harder, Dustfart, and your pathetic IDIOTICONS will
not save you. You ****ed up completely mid-way through bragging and
bull****ting about how good you think you are but aren't. It is now my job
as a k0oKologist to make sure all that rotten egg on your face stays there
and stinks for as long as possible.

>> So, you still reckon you're a programmer, eh, Dustfart? **** me
>> dead. You
>
> Yep, I am.

That's some mighty fine delusion you're having, Dustfart. Next time the
pharmacy fills the prescription for your psychotropic drugs, ask them to
write six extra zeroes on the dispensing quantity and to deliver them by
truck.

Oh, and don't forget to take them all at once.

> I know to atleast know the language syntax before I comment
> on someone elses code, especially if I'm trying to make them look
> stupid in doing so, wouldn't want it to backfire as it has here on
> you.

BWAHAHAHAHAHAHAHAHAHAHA! Dustfart, you just shot yourself in the head.
Again. "atleast [sic] know[ing] the language syntax" is _not_ a
qualification for being a programmer. Only one solitary personal attribute
is required to become a programmer, Dustfart, and you do not possess it; you
never had it. Your incompetent usenet blitherings and your typed-out chaos,
which you have the gall to call a "program", prove you never had it.

There are pitiful, homeless tramps gadding about the streets dressed in
stinking, tatty rags and piss-stained slippers who possess the only requiste
skill, which you lack.

>> waffle on and on about assembler [sic] code and you can't even
>> ****ing well write working code in your precious ****BASIC.
>> BWAHAHAHAHAHAHA! ****ing pathetic.
>
> Well k-man, I made a simple mistake which would have still generated
> an executable.

Don't look now, Dustfart, but every time you go over those freshly-opened,
self-inflicted gunshot wounds to the side of your head you're doing my work
for me.

> Your one line code improvement over my code that you
> dedicated a paragraph bashing on me was not proper syntax, and would
> not compile.

You keep getting told but you never hear, do you, Dustfart? Stop picking at
your self-inflicted wounds, you dumb ****.

You are the one who is bragging and inflating your worthlessness in a vain
attempt to make it into something, Dustfart. Not anyone else. You can polish
a turd until it looks like burnished bronze, but it is still a turd,
Dustfart. You are too stupid to realise that it is irrelevant that the code
would not compile. What is relevant, Dustfart, is that you actually compiled
it.

No doubt you need that explained to you because, clearly, you lack
sufficient discernment skills to understand the point being made.

You do not even have the ****ing halfwit about you to state that code "will
not compile" so as to at least _give_ the impression you possess the simple
ability to think ahead. Instead you admit to compiling the code before
declaring that the code "would not" compile. In short, Dustfart, you could
not assert with even a single, paltry shred of confidence that the code
would not compile beforehand.

**** me dead, Dusfart, freaking squirrels stowing acorns for next winter are
think ahead better than you.

I will take your false accusation of reading the manual over your bragging
claim that a$=string$(24,"+-") did something that it does not do. And I will
take that kind of false accusation over your endless series of utterly inept
cockups and backpedals any day of the week.

> My programming mistake resulting in a less functional program, yours
> resulted in no functional program at all. <g>

Dustfart, what sort of a ****ing retard are you to keep poking your fist
into the gunshot wounds in the side of your head to make them start bleeding
again whilst at the same time declaring "NEENER! NEENER! It's just a
scratch!", only to end up staring blankly at the screen with a gormless grin
or your stupid gob?

> a$=string$(24,"+-")
>
> that will do the same as the code above and below.
>
> a$="+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-"

BWAHAHAHAHAHAHAHAHAAH! LMAO@you

--
alt.usenet.kooks - Pierre Salinger Memorial Hook, Line & Sinker:
September 2005, April 2006, January 2007.

"Now I know what it is. Now I know what it means when an
alt.usenet.kook x-post shows up."
AOK in news:ermdlu$nli$1@registered.motzarella.org

[4Q]

Dustin Cook wrote:
> On Feb 25, 12:11 am, "Kadaitcha Man" <nntp.n...@gmail.com> wrote:
> > > </quote> childish code. No wonder they
> > > call it BASIC (read: code for children)
>
> Actually, it's not quiet basic.. See below, as I tear K-man to
> shreds

Well I hope you do a better job of it
than the last time you tore him to bits
(in your mind) *grin* Back in 2005 when
you first ran into KM and AUK I actually
felt sorry for you. I was under the
impression you was being bullied, but
I guess was wrong. You invite trouble
and conflict. I like a bit of malicious
mischief now and a again and I guess
this time I'm going to sit back and enjoy
this... <LOG ON> Set Webpage = 4Q


<snip>

>
> > woefully inefficient code requires values to be moved left, right and
> > centre, then all the way back again before a result is obtained. I use the
>
> Ouch, I don't think you realize how close asic really is to
> assembler... Your loss.
>

*Shrug* You are using it as BASIC
not assembler. One or two Int86 calls
does not make you an assembly language
coder. This is why people like Mandragore
,T2000, MrSandman laugh at you whenever
you open your mouth.

<snip>

>
> You don't actually do much with assembler do you?

*laugh* You clueless ****tard, it's
you that doesn't have a clue about
assembler.


>Well anyways, when
> asic compiles the binary, the resulting assembler code assigns
> 80characters of memory for each string variable I use. Regardless of
> whether or not I use all of the space, the location of the variable is
> known the whole time my code is running. Nothing need be, moved.

You wouldn't be using ASIC's 80characters
if you had a clue about assembler.
You'd be using the _DATA segment in
one of them FAR calls (you clueless
****ing twat).


> Overwritten as you wish, but moved, not unless you want too. If you
> don't like this design, you may wish to take it up with Asics author,
> I'm unable to evade this limitation myself.

You've had 15 ****ing years to solve
this limitation. Now I know you don't
have any .ASM files, you utter code fake.

Hello, McFLY... HELLO!


_DATA segment word public 'DATA'
s@ label byte

db 'Dustin Cook You Stupid Turd'
db 0
_DATA ends



<snip> cut and pasting the ASIC manual
(someone elses work) will not work
as smoke and mirrors you ****ing turd
in a blender.

> converted from
> strings when read. String variables and constants are written
> out as ASCII
> strings terminated by a null character (however, the null can be
> suppressed). Thus, string variables when written to disk, take
> the same
> space byte for byte as string constants.
>
> The reason behind fixed length string variables was avoidance of
> string
> "garbage collection". In addition to slight performance
> advantages, there
> is the added benefit of providing a string memory address which
> never
>
>
> Page - 141
>
>
>
> changes. Thus once VARPTR retrieves the address of a variable,
> you never
> have to worry about it changing.
> EXE File Memory Map
>
> The following describes the structure of the ".EXE" file created
> by ASIC.
> In the COM file format the code, data, and stack are all in the
> same memory
> segment. In an ASIC EXE format file, the code, data, and stack
> each reside
> in their own segment. Addresses are given as offsets from the CS
> (Code
> Segment), DS (Data Segment), or SS (Stack Segment) registers.
>
>
> Description Address Range
> ------------------------------ -------------
> Program Segment Prefix (PSP) CS: minus 00FF
> (Created/Required by DOS, and
> immediately precedes the
> code segment)
> |
> |
> v
> Code Segment (CS
> User Program 0000 +
> |
> |
> v
> System Subroutines Address Varies
> |
> |
> v
> Data Segment (DS
> Program Data Area #1 0000 - 0102
> String Conversion Buffer 0103 - 0109
> Input Buffer 010A - 015B
> Screen Width 015C
> Color/Attribute Byte 015D
> Screen Graphics Mode 015E
> Cursor Position 015F - 0160
> File Control Table 0161 - 0169
> ERROR System Variable 016A - 016B
> System Subroutine Vectors 016C - 017F
> EXTENDED System Variable 0180 - 0181
> RND Seed 0182 - 0185
> Math Work Area 0186 - 018D
> DEFSEG System Variable 018E - 018F
> Start DATA Block Pointer 0190 - 0191
> Current DATA Block Pointer 0192 - 0193
> Reserved for future use 0194 - 0195
> Optional System Sub Vectors 0196+
> and Work Areas (decimal math option)
> Program Data Area #2 Address Varies
> |
> |
> v
> Stack (SS (builds downward) 0000 - 07D0 (0FA0--debug
> mode)
>
>
> Page - 144
>
>
>
> NOTE: The format of an EXE file created using the
> "B/OBJ" option is essentially the same as the one
> produced by the "B/EXE" option, except that the "B/OBJ"
> output file may contain additional code or data
> segments linked in from other OBJ or LIB files
>
> Read it
> 0wned k-man. Full documentation for asic as well as the compiler can
> be found on my site, if your inclined enough to educate yourself.
> follow this link:
> http://bughunter.it-mate.co.uk/asic500.zip

Or he could just get it from a reputable
source where he'd be guaranteed not to
have something nasty installed like a
backdoor BugHunter Trojan.

*Simtel* <-- He could get IBRARY.LIB
as well, you know the one you code ripped

> and if you dont want to touch the problem, but want to see the docs
> alone, go here:
> http://bughunter.it-mate.co.uk/asic.txt
>
> There ya go, enjoy!
>

FOAD! I thought you was dying from AIDS?
How long have you got left? You look
like you are in the advanced stages of
the disease, but just gives us an eta
so we have got a rough idea when you plan
to launch the BugHunter surprise.


4Q

[bughunter.dustin@gmail.com]

On Feb 25, 2:54 am, "4Q" <paul_z...@hushmail.com> wrote:
> Dustin Cook wrote:
> > On Feb 25, 12:11 am, "Kadaitcha Man" <nntp.n...@gmail.com> wrote:
> > > > </quote> childish code. No wonder they
> > > > call it BASIC (read: code for children)
>
> > Actually, it's not quiet basic.. See below, as I tear K-man to
> > shreds
>
> Well I hope you do a better job of it
> than the last time you tore him to bits
> (in your mind) *grin* Back in 2005 when
> you first ran into KM and AUK I actually
> felt sorry for you. I was under the
> impression you was being bullied, but
> I guess was wrong. You invite trouble
> and conflict. I like a bit of malicious
> mischief now and a again and I guess
> this time I'm going to sit back and enjoy
> this... <LOG ON> Set Webpage = 4Q
>
> <snip>
>
>
>
> > > woefully inefficient code requires values to be moved left, right and
> > > centre, then all the way back again before a result is obtained. I use the
>
> > Ouch, I don't think you realize how close asic really is to
> > assembler... Your loss.
>
> *Shrug* You are using it as BASIC
> not assembler. One or two Int86 calls
> does not make you an assembly language
> coder. This is why people like Mandragore
> ,T2000, MrSandman laugh at you whenever
> you open your mouth.
>
> <snip>
>
>
>
> > You don't actually do much with assembler do you?
>
> *laugh* You clueless ****tard, it's
> you that doesn't have a clue about
> assembler.
>
> >Well anyways, when
> > asic compiles the binary, the resulting assembler code assigns
> > 80characters of memory for each string variable I use. Regardless of
> > whether or not I use all of the space, the location of the variable is
> > known the whole time my code is running. Nothing need be, moved.
>
> You wouldn't be using ASIC's 80characters
> if you had a clue about assembler.

Heh.. Maybe you ignored what was posted. All of the internal asic
commands are setup for that limitation. It would take a bit more than
the modification to the data statement your suggesting.
If I'm going to do that much after compilation patching, I might as
well do it all in assembler. the time taken would be about the same.

> <snip> cut and pasting the ASIC manual
> (someone elses work) will not work
> as smoke and mirrors you ****ing turd
> in a blender.

No smoke and mirrors 4q, its a design decision the author made.. It's
a bit more than a couple of bytes to fix it. Any internal asic command
is setup for this silly limitation. I might as well do it in pure asm
if i'm going to go thru that much trouble.

> > follow this link:
> >http://bughunter.it-mate.co.uk/asic500.zip
>
> Or he could just get it from a reputable
> source where he'd be guaranteed not to
> have something nasty installed like a
> backdoorBugHunterTrojan.

4Q, you know at somepoint, you'll have to back that claim up right? or
risk losing what tiny amount of credibility you have left since
****ing with me. *grin*

> *Simtel* <-- He could get IBRARY.LIB
> as well, you know the one you code ripped

Really? I already posted my disassembly. Point out the differences
please. I already gave you the clue, retf is present in mine, not in
his. The beginning data is the same, and if you see asic.doc, you'll
see I couldn't "rip" it, you either setup with it the way asic wants,
or you cant exchange data between your routine and the one that called
it. Twist what I've said all you like, everything's in the doc
file.

> > and if you dont want to touch the problem, but want to see the docs
> > alone, go here:
> >http://bughunter.it-mate.co.uk/asic.txt
>
> > There ya go, enjoy!
>
> FOAD! I thought you was dying from AIDS?

Ouch 4Q, Do you remember what I said about credibility? I have a liver
problem that I've had since birth, I already went over that too. I
have no diseases of any kind, thanks all the same.

> How long have you got left? You look
> like you are in the advanced stages of
> the disease, but just gives us an eta

Ouch, I've really toasted your ass here eh? Have you run dry of
anything useful old buddy? Have I kicked the great 4Q's arse at his
own game?

Hah!

> so we have got a rough idea when you plan
> to launch theBugHuntersurprise.

Ouch, another shot at your credibility. Damn dude, I don't think you
have any left now.

Hey, btw I sent you an email; I hope you enjoy the statistics. to
verify the email claim, just type "bughunter" in any of those search
engines. I carbon copied the email to various individuals, good luck
trying to alter anything.

And since I see you want the kookologists involved, they may suck on
the email I sent you as well:

BugHunter MalWare Removal Tool is first link at the following search
engines... and I didn't have to pay
for any of this. I certainly do appreciate the popularity. It's
evident my hit counter isn't showing all the traffic...
hehehe


www.google.com
www.yahoo.com
www.ask.com
www.dogpile.com
www.msn.com
www.alltheweb.com
aolsearch.aol.com

and 2nd place on
www.altavista.com

Thanks for your continued support for BugHunter!

PS, I have sent this to 4Q also, I know, it wasn't very nice, rubbing
his nose in it like that, but.. I couldn't resist.. *grin*


--
Dustin Cook
author of BugHunter - MalWare Removal Tool
http://bughunter.it-mate.co.uk

[Kadaitcha Man]

bughunter.dustin@gmail.com Thou doghearted poor unvirtuous fat knight.
Thou artless depender on a thing that leans. Thou courteous destroyer.
Thou viperous worm. Ye yammered and ye plagued:

> No smoke and mirrors 4q, its a design decision the author made.. It's
> a bit more than a couple of bytes to fix it. Any internal asic command
> is setup for this silly limitation. I might as well do it in pure asm
> if i'm going to go thru that much trouble.

Is that input asm or output asm, Dusftart?

> 4Q, you know at somepoint, you'll have to back that claim up right?

*LMFARO* *COUGH* *CHOKE* *GRUNT* *COUGH* *SPLUTTER* *WHEEZE*

That, coming from you, you who cannot back up your claim to have ever
written anything other than a complete pile of ****e.

BWAHAHAHAHAHAHAHAHAHAHAH!

> or risk losing what tiny amount of credibility you have left since
> ****ing with me. *grin*

BWAHAGAHAGHAGHAGAHGHAGAHGAGAHGAHGAGAGAGAGAGAAGGAGA GAGAGAGAGAAGGA!!!

*CHOKE* *COUGH* *CHOKE* *GRUNT* *CHOKE* *COUGH* *CHOKE* *WHEEZE*
*NNEEDDD* *AMBULANCE* *HHHHHHhhhELPPPP!!!*

"risk losing what tiny amount of credibility you have left", wrote the
consumate blockhead who has zero credibility.

<wipes tears of laughter from eyes>

That was truly the funniest thing I've read in years.

> Ouch 4Q, Do you remember what I said about credibility?

Who will ever forget it, Dustfart?

> I have a liver problem<*****SLAP>

It's the sentiment that counts. **** off and die.

>> How long have you got left? You look
>> like you are in the advanced stages of
>> the disease, but just gives us an eta
>
> Ouch, I've really toasted your ass here eh?

Take more psychotropic drugs, urgently.

> Have you run dry of
> anything useful old buddy? Have I kicked the great 4Q's arse at his
> own game?

No. But then you and truth aren't exactly on familiar terms, eh.

<spam snipped>

--
alt.usenet.kooks - Pierre Salinger Memorial Hook, Line & Sinker:
September 2005, April 2006, January 2007.

"Now I know what it is. Now I know what it means when an
alt.usenet.kook x-post shows up."
AOK in news:ermdlu$nli$1@registered.motzarella.org