Re: RosAsm - right click

• Previous message: Annie: "Re: why is nobody developing assembly IDE's"
• In reply to: The Wannabee: "Re: RosAsm - right click"
• Next in thread: The Wannabee: "Re: RosAsm - right click"
• Reply: The Wannabee: "Re: RosAsm - right click"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Wed, 26 May 2004 03:27:25 +0100

The Wannabee wrote:
> Beth wrote:
> > Wrong; NTFS (Windows) and ext3 (Linux) all the way...only
time I
> > ever see FAT is for floppies (which are rarely needed these
days
> > :) because you're not given a choice in the matter
there...oh,
> > and I suppose there's that ISO / Joliet nonsense for CDs too
> > (which I confess to never having looked into to really know
> > what's going on there specifically)...
> >
> > Note: If you're still using FAT32 under XP or some other
> > NT-based version, then open up a DOS prompt and type
"CONVERT
> > /?" to discover a handy little utility that can
automatically
> > change that situation on your behalf...NTFS has journalling,
> > security, quotas, streams, compression and so forth...it's
also
> > designed to lay out files in a fast access
manner...although,
> > yes, this otherwise "nice idea" is generally defeated in
> > practice by the journalling and the fact that Windows is
slow,
> > bloat and crap, anyway...
>
> Hi Beth ;-)

Wannabee :)

> So you are even fatter (FETT/FETA!) :-)? No. When it comes to
NTFS, I am
> against on prinisple matters. Until I know exaxtly what it
does. And I
> dont. Better safe than sorry.

It's an evolved HPFS ("High Performance File System"),
basically...

http://www.ntfs.com/ntfs_basics.htm

http://linux-ntfs.sourceforge.net/ntfs/index.html

http://www.lesbell.com.au/hpfsfaq.html
(about HPFS but NTFS is an "evolved" version of HPFS)

Blah-blah-blah...

Google!!

> For all I know it has properties that will
> one day disallow me to play my MP3s.

No, that's called "Palladium"...

> Strange how you Beth seems to hate
> M$ so much, but still promote using their technology.

Ummm, I'm the one working on and promoting a Linux
assembler...you're the one evangelising a "Win32 specific"
assembler with lines like "RosAsm is the future and all other
assemblers will die when it realises its potential!" and so
forth...

I was NOT "promoting" NTFS...I stated "_IF YOU'RE STILL USING
FAT32_" as a condition...and, even then, I took a pretty
underhand stab at Microsoft that the "least distance" design of
NTFS is actually logically defeated by having a "journal" stuck
in the middle of the drive where, for journalling to function
properly, it must always return to write the current operation
to the journal before actually doing that operation...it's a
logical contradiction to lay out the files near each other to
reduce the distance the read / writes heads have to travel...but
then have one big "journal" file in the middle that, oh, you
have to go and write down all your current operations to the
"journal" before actually doing them...so, you're always rushing
back and forth to the "journal" file...

[ Nope, the "journalling" should also be delibrately "localised"
in the same way...so that the "journal" gets written right next
to the files being operating on and divided across the file
hierarchy...how do you find the "journal" after a crash?
Easy...when the read / write head is about to move from one
directory to another, it drops a note of where it is going into
that directory's "journal"...and proceeds to do that for each
directory until the directory where the work is to be carried
out is reached, where the "journal" records what operation it's
about to do...then the "least distance" concept is not defeated
(the read / write head is either literally hovering over the
journal in that directory or a file right next to it - "least
distance" - that it's carrying out the actual operation in the
journal about...when moving from directory to directory to reach
a destination to perform an operation, it simply drops a note of
this in that directory's "journal" about where it is
going...leaving a "paper trail" from the root directory pointing
to where the current operations are...when directed to some
other directory elsewhere and it's a relative path
("..\..\Other") then it simply "undoes" the "paper trail" on its
way back, changing the entries to guide the trail to this new
directory...if it's an absolute path from the root directory
("C:\Folder\Directory\File.dat") then, well, when it returns to
the root directory it can "cheat" - no need to "back-track" the
entire distance "undoing" the "paper trail" in all the
journals - by just returning to the root directory and wiping
out the entry in that directory, severing the "trail" at its
start...and, there, journalling and "least distance" without
actually conflicting with each other... ]

Anyway, as I was saying, I was NOT promoting NTFS (it doesn't do
the above, for example...and, thus, in many is, indeed, crap
;)...I was actually simply insulting FAT more than NTFS, as an
even worse file system again...the "_IF YOU'RE STILL USING
FAT32_" condition was an integral part of what I was saying
there...that's, of course, kind of why I wrote it, on the
presumption people might, like, kind of read it and understand
it and that kind of thing...you know?

Think of it more like: "If you're still poking your own eyes out
with red hot pokers, then consider being punched in the face
instead"...this is not a suggestion that being punched in the
face is a good thing, it's a suggestion that it's better to
getting your own poked out with red hot pokers..."better" is a
comparative and, thus, _relative_ word...but this doesn't always
mean "better" has anything to do with "good", if you catch my
drift...neither having your eyes poked out or being punched in
the face is "good"...but one is, indeed, "better" than the
other...and it would be "best", for sure, not to have either
your eyes poked out nor a punch in the face ;)...

> Maybe I am even more paranoid than you ?

Quite possibly; But, ummm, is this some underhand "you're a mad,
paranoid nutter!" comment written between the lines here?
Actually, I'm not that paranoid, really...I simply apply the
common sense military-style thinking of "Hope for the best...but
always _plan for worst_"...it's a method that avoids all
disappointments and nasty surprises, without totally requiring
walking around with a big frown, depressed at everything ;)...

> XP suck, but you use it.

But it's the most stable Windows there is...note, again: No
"promotion" there...they're all unstable, slow, bloated security
nightmares...all of them...but XP is the least unreliable so
far...yes, it's slow and bloated...yes, it's got stupid default
security settings...yes, yes, yes, to a million things...but,
overall, of all the mountains of crap Microsoft have offered
over the time, XP is the least crap of a whole big bunch of
crap...

XP is also an NT-based kernel...NT was actually put together by
hired-in VMS programmers originally and, thus, though
Microsoft's grubby fingerprints are all over it making it crap
once more, this does mean that in _some_ small little ways here
and there, _NT-based_ Windows do have some reasonable and
alright things...if you like, the bits MS didn't touch but hired
in people who actually knew what they were doing to implement it
for them, are actually "not bad" in places...and, yeah, to a
degree, NTFS is part of that...FAT is a cheap and cheerful
Microsoft "hack" that has been hacked and hacked until...well,
have you seen the "long filenames" documentation and how FAT
implements that? It's a crap design, badly implemented and then
hacked out of all recognition into a total mess...it ain't to
say NTFS is the best file system but, well, at least it _IS_ a
file system...FAT is just some "cheap hack" stuck onto DOS
without any great thought being put into it at all...and, over
the years, it's been mutilated by Microsoft...much like it's
hard to call DOS itself an "operating system" or those first
pathetic attempts to write Windows as a DOS application which
couldn't even overlap windows is as equally hard to call a
"GUI"...FAT is difficult to take seriously as really a "file
system"...

> Win98 1st edition, is times faster.

Indeed, I don't doubt it is; But part of the reason why that's
the case is: No security, no FS journalling, no proper
microkernel structure, etc....much like a very simple assembler
that has no macro system and no constant expression support and
can only deal with the very, very simplest of raw mnemonics and
nothing else...that an assembler like this could very well be
many times faster than an assembler with a good macro system and
able to deal with complex constant expressions and data typing
and "scope" and conditional assembly and...and...and a ton of
other useful features like that...

But the _reason_ that the simpler assembler is faster is simply
because, well, it just isn't as good a tool and is only running
faster because it has much less capability...

So, indeed, I don't doubt that Windows 98 will, for those _five
minutes only_ it's running before it bombs out to the "blue
screen of death" again and again, go faster than XP...but if you
add up all the time of your PC constantly rebooting because it
crashes every five minutes and all that work you lose in the
crash that heads straight to "digital oblivion" (the place from
which NOTHING returns...kind of like a black hole, I suppose ;),
then the speed advantage is soon dwarfed by the fact that you
can't actually get anywhere...because, yes, you're speeding
along and then - bang! - the BSOD and then there goes all that
work and you've got to start all over again after a long
reboot...until - bang! - BSOD again...there goes all that work
again...and the loooong reboot...then we try to pick up where we
left off and - bang! - BSOD once more...

Not that XP isn't capable of a BSOD but they are now at least
rare happenings that you actually have to work hard to
cause...price of this slightly better reliability and security
and a recoverable file system and so forth? Takes an extra
second to load something sometimes...ooh, big deal...and not
everything's slower necessarily...some things are about the same
and could that be some DirectX stuff running slightly faster
because while Win98 still carries some 16-bit code for some of
these things, XP has finally gotten most things 32-bit (I would
say "all", except, simply, I don't trust Microsoft...they've got
something hidden away somewhere that they ain't talking about, I
bet ;)...

> My asm applications that are pretty slow on XP (graphics), are
so
> fast drawing on win98 1st edition that I have problems sizing
them....
> because they react so fast to the size operation.

Your programs have problems reacting to a window sizing because
of "fast reactions" in Windows 98? What kind of problems? Starts
drawing it wrongly?

Oh, please, Wannabee...who do you think you're speaking to? A
line like this may work on others but...well, single-threaded,
right? Sits in a message loop and then uses GDI to respond to a
WM_PAINT?

There's no "timing" involved...it's single-threaded and
sequential...the speed will have _no effect_ on how it
operates...only on how quickly it draws things and nothing
else...

Or, put another way, if you ain't just making this up and your
ASM programs really are drawing things wrongly because they
"react too fast" to the sizing operation, then you've just _got
to be_ coding it wrongly somewhere...

Order of events during a size drag:

GetMessage -> WM_PAINT -> "PaintProc" draws the entire window ->
GetMessage -> WM_PAINT -> "PaintProc" redraws entire window ->
GetMessage -> WM_PAINT...etc., etc....

So, how "fast" it reacts isn't just Windows but your own
WM_PAINT handler...which, under Windows' message loop scheme in
a single-threaded program, _WON'T_ return to get another message
in the loop until you've drawn what you need to draw...

Also, to add insult to injury, WM_PAINT messages are
_consolidated_ together on the message queue..._unlike_ other
messages, these don't build up on the message queue in the same
way, however "fast" they are sent to an application...

If you're not making this up, then you must be programming your
ASM routines wrong...these aren't "timing" related operations
and, though event-driven, Windows is still firmly
single-threaded and sequential in its operations (unless, of
course, you delibrately start multiple threads...in which case,
you must be messing up your concurrency constructs that keep the
threads in order...by design, WM_PAINT messages could happen at
any time so, even under a multi-threaded program, this should
have nothing to do with "timing" or you've design it or written
it wrongly...as it doesn't make too much logical sense that
because the system runs a little faster, the graphics should
suddenly screw up...I mean, if you run it on a PC that's three
times as fast again, does the graphics screw up even more
because of the even faster "reactions" of the better hardware?
If it does, you're coding it wrongly and should proceed to
review the entire design of your code)...

> Not so on XP. Somebody told you XP was faster huh? Well, its
not.

I know...I just said that myself...but "faster" ain't
necessarily "better" when you also value things like
reliability, security, recoverability, etc....yeah, yeah, I
know...it's _WINDOWS_ here so this stuff is, indeed, in
incredibly short supply, even with XP...but, well, that's kind
of the point...XP has the smallest crap offering about these
things...but the other Windows are _non-existent_ with this
stuff...totally void...completely absent...

Nobody "told" me anything, Wannabee...I know what's what
sufficiently to have a reasonably useful opinion of it
myself...the only thing I've been told is what you just said
above about Win98 "reacting" so fast that it's somehow defying
its own design...which, if there's nothing wrong with your code,
doesn't sound too credible...oh, I'm sure it runs faster...but
not this rather bizarre "so fast, it stops working properly!"
assertion...in which case, if this is the kind of quality I
should expect from people "telling" me what system is best and
so forth, I was right not to pay any attention...

I do have Windows 98 on a CD here and used to run it...but XP
came with my PC and I gave it a try...and, yeah, nothing to
write home about...no miracles anywhere...but, sorry, it's the
best Windows that Microsoft have authored so far...of course,
every version of Windows is utter crap...but it's the "least
crap" out of a whole bunch of really crap things...

> M$ OS are allways slower, than last time, and XP is no
exception.

Yup; Quite right there...in fact, MS OSes suspiciously seem to
slow down in a very subtle way as the pre-planned release date
for the next Windows release draws near, no matter how much
maintenance you do on the thing...I think they must delibrately
put in some kind of "memory leak" style of thing into it so that
you can't carry on using it indefinitely without re-installing
it...and then that's when they hit people with "New! Windows XP
2!" adverts...

> At least here, this is true. Theres
> somethings XP seems to do faster, like font drawing, but for
the things I
> need, antialized stretched bitmaps, or rather HALFTONE
bitmaps, Win98 is
> at least 3 times faster. I dont know why. Also, I have tried
NTFS, and it
> is NOT faster.

Yeah, NTFS isn't faster...it's slower because it has to keep the
"journal" all the time and has to check security permissions and
there's some more "overhead" in keeping it all ticking over
smoothly...plus, if you've got the compression (or encryption)
switched on, then that's going to require compression /
decompression all the time to slow it down
further...blah-blah-blah...

NTFS isn't faster...but it is _better_...

Note, the comment about "files laid out in a fast access manner"
was immediately followed by a counteraction that this, though,
is _entirely defeated_ by the need to "journal" every single
operation all the time (and that's not the only thing conspiring
to slow it down)...again, please pay attention to what I _AM_
saying, not these strange things you invent that you think I'm
saying...files under NTFS are laid out according to a "least
distance" principle, designed to, in theory, allow faster access
but reducing the movement of the read / write head...BUT, I did
not say it _was_ "faster"...in fact, I said the reverse and
pointed out that this idea was "generally defeated in
practice"...

Hey, English isn't your first language so perhaps you need to
re-read things or something...I _didn't_ say it was "faster", I
said that it was designed to lay out the files in a way to make
access faster but that this was "generally defeated in
practice", citing that the "journaling", for example, requires
that details of operations are written to the journal all the
time so that the FS can be "recovered" after a crash (and due to
this being about recovering after a crash that can happen at any
time, "journaling" _CAN'T_ be cached or anything...it must write
to the "journal" prior to any critical disk operation...where's
the "journal"? Oh, stuffed in a file in the middle of the
disk...so, ummm, that stuff about putting files close together
to reduce head movement? Oops, defeated in practice by the need
to constantly rush off to the "journal" all the time...someone
wasn't entirely thinking clearly while they were designing that,
eh? ;)...

> Maybe thats due to using a slower OS, but Win98 is faster
> on al things I use it for, except for outputting fonts. Now
truth be told,
> XP is better to program DirectX in, because its more stable,
but when the
> app runs, it runs faster on 98. Not really scientifically
tested, but for
> my own apps at least, this is true.

No; That sounds about right to what would be expected...Win9x
often runs faster because, well, it simply _does less_...while
the NT-based stuff does more but runs a little slower because of
that...what NT is doing extra, though, is usually all the stuff
that actually makes it a more reliable system...

[ The fonts? Well, just a case that - like the mouse pointer
routines, which had an annoying "visual artifact" removed - the
routines got re-written, for once, rather than re-used because
it had to be changed from the ground up to support all the new
graphical features like anti-aliasing everywhere and
transparencies (like the "mouse shadow") and that kind of
thing...as that code is newer because it's re-written, they must
have also decided to improve the algorithm while they were there
or something...after all, the mouse pointer routines were
clearly getting "re-use" all the way through from Win3.x until
XP changed it because the same "visual bug" of the pointer
jumping when it's changing shape is present in them all...well,
is it the case that they also simply "re-used" their font
rendering code from Win3.x up until XP...but the new style with
XP and having to add in "clear type" so that the anti-aliasing
worked on laptop screens properly and that kind of thing, meant
that they finally went back over that font code and actually
bothered to re-write it rather than "hack" it some more...and,
like the mouse pointer "bug" was automatically cured by its
re-write, they simply chose a much smarter algorithm or
something when they went back to their font code to re-write
that to support the newer features...well, that's my guess,
anyway, looking at things and thinking what's most likely...only
Microsoft's OS coders could actually say if that's what actually
happened or not :) ]

> Another thing I noticed when I tested XP was : they had
removed OpenGL
> default support, and DirectX on XP ran actually faster than
Direct X on
> 98, when I used Counter Strike. The framerates for DirectX on
XP was
> identical to my OPENGL frames on 98. What the heck is that all
about ? On
> 98 directX frame rates are 1/3 of openGL for CounterStrike. So
DirectX on
> XP is faster, above I was talking about GDI. See you.

Embarassed that OpenGL was doing better than DirectX, Microsoft
removed OpenGL default support so no-one would Hopefully
notice...and then looked at how OpenGL was doing things better
than they were and then just copied it??

Mind you, on Win9x, the DirectX drivers can sometimes be 16-bit,
while they must be 32-bit all the way on XP...depending on that
kind of thing, this could also be a factor, maybe...

But, no, don't know what that is for certain...all a bit
strange, eh? Best not to spend too much brainpower on trying to
fathom out Microsoft...they have no idea what they're doing half
the time and they're the ones actually doing it! ;)

> PS:
> Now I have a problem Betty,

Yes, I know...oh, wait...you mean a _new_ problem? Ah,
well...carry on...

> maybe the oracle will help me?

Maybe; I'm Trinity, remember...not the Oracle...

Heck, I couldn't even point out where Delphi is on a map...

[ Although, at least I'd do better than these fine examples of
"American geography" from Phil's website:

http://fatphil.org/errors/american_geography.jpg
(Lucky Putin wasn't wanting to visit Switzerland...and where did
Austria move to when no-one was looking? ;)

http://fatphil.org/errors/american_geography2.jpg
(this one is, though, absurdly bad...what the hell is Iraq doing
there?!? And wasn't the country they're now labelling "Czech
Republic" just referred to as "Switzerland" on the last map?
Yup, next to Poland and the same shape...they can't even be
consistent, let alone actually, you know, looking it up on an
atlas that, like, has the countries in the right places (I mean,
there's got to be one atlas or globe in America that's got the
countries labelled correctly, surely? ;)...so, now where'd
"Switzerland" gone and moved to? "These darn European countries!
They just won't stop moving around!! Crap! Umm, let's just bomb
the lot of them!!" ;)...

Kind of makes you worry...did Bush actually mean to invade
Poland - you know, like his right-wing idol Hitler did - but
they accidentally sent all the troops to Iraq? And, well:
"seeing as we're here, we might as well invade this country
instead, yeah?"...this could actually go some way to explaining
why they thought there might be WMD and had all that "evidence"
to present...it was actually evidence of WMD programmes in
Israel but they stuck the wrong labels on the files and folders
because they'd been depending on CNN's maps to work out where
all the countries were ;)

Woah! Cool, Phil...you're the "mathematician" that has been
creating prime numbers that just so happen to coincidentally be
illegal under the DMCA?

http://www.theregister.co.uk/2001/09/11/worlds_first_decss_execu
table_prime/ ]

> Read my entry in this thread to learn about the problem. Then
come back an
> teach me all about it :-)
>
>
http://easbell.quanta-it.com/RosAsmForum/viewtopic.php?p=2054#20
54

Ummm, what is it that you're doing there exactly? Creating your
own COM object or something?

> If you help me, you get a free directshow app, when its done
:-)) :-)) I
> put you in the credits. Promise.

Oh, it's "DirectShow"...that wasn't part of the core DirectX
package until DX8 or whatever...and I've never really ever
looked at it yet...can't really help you there, as I'm probably
more "newbie" than you are with "DirectShow"...oh, well...didn't
want to be put in the credits, anyway...but that's academic, as
I don't really know what you're doing there...and by the time I
study up on "DirectShow" and unravel what all your macros means,
you'd have probably solved it yourself or found someone who does
know what's going on there...sorry about that...

Beth :)

• Previous message: Annie: "Re: why is nobody developing assembly IDE's"
• In reply to: The Wannabee: "Re: RosAsm - right click"
• Next in thread: The Wannabee: "Re: RosAsm - right click"
• Reply: The Wannabee: "Re: RosAsm - right click"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]