Msvcrt.dll v6.0.9782.0. help

astral wrote:
Here is error code:

FIREFOX caused an invalid page fault in
module MSVCRT.DLL at 0167:7800d6f3.
Registers:
EAX=00000066 CS=0167 EIP=7800d6f3 EFLGS=00010216
EBX=00001521 SS=016f ESP=00d9d8d4 EBP=00d9d8dc
ECX=000003a4 DS=016f ESI=05264fff FS=3b8f
EDX=00000003 ES=016f EDI=0526f0b0 GS=0000
Bytes at CS:EIP:
f3 a5 ff 24 95 88 d7 00 78 23 d1 8a 06 88 07 46
Stack dump:
0526ea22 00001522 00d9d9c8 6010532c 0526ea22 05264971 00001521
00d9d9e8 023f1870 023d8f54 601052e1 00d9d9e8 05264971 00001521
05264971 60105e6c


The only thing that Firefox has some great add-ons like Firebug,
Opera can only wotk with some cutted vers of Firebug.


http://www.google.com/search?hl=en&s... t+msvcrt.dll
Google has about 1040 hits for "firefox invalid page fault msvcrt.dll".

Read through a bunch & get back to us with a plan.

"MyNews" wrote in message
...
Look at Opera it the only one that care about Windows 98 and it up
to date and will not crashes.
There will be one Warning that says
The system library Msimg32.dll is missing or too old, so certain
Transparency effects will be slow
and possibly not drawn correcting. obtaining the library from a
Windows ME installation
and placing it in your Windows system directory will fix this.

it's needed with Win98
just check the box
Do not show this dialog again.
And check Close


"astral" wrote in message
...

"MyNews" wrote in message
...
we Working with Windows 98, not XP


"Sjouke Burry" wrote in
message ...
MyNews



wrote:http://web.archive.org/web/200604111....forteinc.com/
agen
t/features.php
I did all the updates for IE6 sp1 and Msvcrt.dll did not came
with it..
I at Windows Update going to download Microsoft .NET Framework
version
1.1
I'll do a Search for Msvcrt.dll to see if it come with it!

A file search at my xp machine came up with about 13 dll's.
3 of them older then the one you want,
one in graphics workshop, 6.0.8168.0,
in java/jre6/bin, 6.0.8337.0,
and macromedia player 5.0.0.7128.
So you might look around on some computers and find some to
experiment.
----------------


Firefox crashes when I going into a some page containing flash I
belive. With MS Explorer nothing happens but Mozilla Firefox
2.0.0.20 crashes. I belive this link about this issue:
http://support.microsoft.com/kb/895959/

I replaced with recommended Msvcrt.dll v6.0.9782.0., but this not
help.

--
Thanks or Good Luck,
There may be humor in this post, and,
Naturally, you will not sue,
Should things get worse after this,
PCR

FromTheRafters wrote:

legg wrote:

"Bill in Co" wrote:

legg wrote:

snip
If you are looking for approximate age of the .dll
version, look at the 'modified' date. The 'created' date
only indicates when it was installed in the machine.

I think the created date indicates when the file was
initially created - NOT when it was installed. The
modified date indicates the latest revision date (for the
particular version on his machine).

You'd think so, wouldn't you. In fact the create date is the
date the file/rev is placed on the disc.

Technically, it (the file) isn't placed on the disk. The
terminology is actually good. The *file* is "created" on the
disk and the content of the remote file (the program,
document, or whatever) is transferred to that newly created
file. There is sometimes a way to retain the source's 'file
creation date' with some protocols - the just modify the
creation date to match the source.

The terminology used is actually insufficient. It doesn't (allow
to) differentiate between the creation-date of a file and the
creation-date of an _instance_ of a file.

When it comes to digital files, what is the difference between a
copy of the original and that of the original copy? .. i mean
except for the different creation dates of the file-instances.



The "program" creation date might be inside the resource
section - the date it was compiled.

[...]


--
"I ain't different from anyone
It ain't no use talking to me
It's just the same as talking to you."

System Requirements of Firefox 2.0.0.2032-Bit versions

•Windows Vista
•Windows XP
•Windows Me
•Windows 2000
•Windows 98
64-Bit Versions

•Windows Vista x64
•Windows XP x64
Download Firefox 2.0.0.20 (5.77 MB)
http://www.oldapps.com/firefox.php?o...fox=7?download

The list Firefox for Windows 98

+++++++++++++++++=

System Requirements of Firefox 332-Bit versions

•Windows Vista
•Windows XP
•Windows 2000
64-Bit Versions

•Windows Vista x64
•Windows XP x64

See not for Windows 98

"MyNews" wrote in message
...
"astral" here your fix's

http://www.microsoft.com/downloads/e...displaylang=en

Open have Dragonfly
Makes that FIREFOX look like a childs toy!

MyNews wrote:


"Etal" http://www.mdgx.com/files/VS6SP6U.EXE

Visual Studio 6 Service Pack 6 Update" (VS6 SP6
Update) is for XP

Perhaps the SP6 as issued by ms, but the above referenced file is
not exactly that but actually an installer modded to install the
latest versions that will work with Win98 onto Win98. It has been
updated and contain files from as recently as (2009-03-24).



Windows 2000 Msvcrt.dll is 6.10.9844.0 Microsoft ® Visual C++ 1981-1999

Windows ME Msvcrt.dll is 6.10.8637.0 Microsoft ® Visual C++ 1981-1999

Windows 98 Msvcrt.dll is 6.00.8397.0 Microsoft ® Visual C++ 1981-1998

now the Win ME will work on 98


I'm not sure what you mean by "is" .. but if you mean "the latest
version for ... is" you are wrong about Win98 since ms has
[msVCRt.dll] 6.00.8797.0000(2000-03-07) inside the
(2000-11-15) Visual Studio 6.00.8797.0 Run-time Redist (Q259403)
for OS-versions including Win98.

http://support.microsoft.com/kb/259403/


--

Ok Etal I Download it and install we see
Put it between Windows 2000 and Windows ME

Ver. 6.00.8798.0
1981-1998
But it do up data it!

Good Info Etal

Windows 2000 Msvcrt.dll is 6.10.9844.0 Microsoft ® Visual C++ 1981-1999
Windows ME Msvcrt.dll is 6.10.8637.0 Microsoft ® Visual C++ 1981-1999
Windows 98 Msvcrt.dll is 6.00.8397.0 Microsoft ® Visual C++ 1981-1998

I'm not sure what you mean by "is" .. but if you mean "the latest version
for ... is" you are wrong about Win98 since ms has
[msVCRt.dll] 6.00.8797.0000(2000-03-07) inside the
(2000-11-15) Visual Studio 6.00.8797.0 Run-time Redist (Q259403)
for OS-versions including Win98.

http://support.microsoft.com/kb/259403/

Etal wrote:
FromTheRafters wrote:

legg wrote:

"Bill in Co" wrote:

legg wrote:

snip
If you are looking for approximate age of the .dll
version, look at the 'modified' date. The 'created' date
only indicates when it was installed in the machine.

I think the created date indicates when the file was
initially created - NOT when it was installed. The
modified date indicates the latest revision date (for the
particular version on his machine).

You'd think so, wouldn't you. In fact the create date is the
date the file/rev is placed on the disc.

Technically, it (the file) isn't placed on the disk. The
terminology is actually good. The *file* is "created" on the
disk and the content of the remote file (the program,
document, or whatever) is transferred to that newly created
file. There is sometimes a way to retain the source's 'file
creation date' with some protocols - the just modify the
creation date to match the source.

The terminology used is actually insufficient. It doesn't (allow
to) differentiate between the creation-date of a file and the
creation-date of an _instance_ of a file.

When it comes to digital files, what is the difference between a
copy of the original and that of the original copy? .. i mean
except for the different creation dates of the file-instances.

I'm still assuming it's the date the file was compiled: the compiled date
stamp. Subsequent *identical* copies of it (and their new dates (if any)
would seem to be of little use, as long as the code was identical to when it
was first compiled.

For example, if some DLL file has a creation date of 12/2004, then who cares
about the dates of any newer copies *so long as the file contains the
originally compiled code of 12/2004* - meaning no changes or revisions were
made to it.



The "program" creation date might be inside the resource
section - the date it was compiled.

[...]


--
"I ain't different from anyone
It ain't no use talking to me
It's just the same as talking to you."

Etal wrote:
FromTheRafters wrote:

legg wrote:

"Bill in Co" wrote:

legg wrote:

snip
If you are looking for approximate age of the .dll
version, look at the 'modified' date. The 'created' date
only indicates when it was installed in the machine.

I think the created date indicates when the file was
initially created - NOT when it was installed. The
modified date indicates the latest revision date (for the
particular version on his machine).

You'd think so, wouldn't you. In fact the create date is the
date the file/rev is placed on the disc.

Technically, it (the file) isn't placed on the disk. The
terminology is actually good. The *file* is "created" on the
disk and the content of the remote file (the program,
document, or whatever) is transferred to that newly created
file. There is sometimes a way to retain the source's 'file
creation date' with some protocols - the just modify the
creation date to match the source.

The terminology used is actually insufficient. It doesn't (allow to)
differentiate between the creation-date of a file and the creation-date
of an _instance_ of a file.

The "file" doesn't matter. The file is created by the filesystem, *not*
the programmer. The programmer created the content that was stored in
the file. It's like throwing out all of your cookies because the the
cookie jar your grandmother gave you is so old.

When it comes to digital files, what is the difference between a copy of
the original and that of the original copy? .. i mean except for the
different creation dates of the file-instances.

No difference, and that is the point. You put your cookies in a new jar,
and they are still the same old cookies. Creation date and modification
date are filesystem artifacts - compile date (for executables) tells you
when the author compiled the program - it is not a filesystem thing.

Bill in Co wrote:

Etal wrote:


The terminology used is actually insufficient. It doesn't
(allow to) differentiate between the creation-date of a file
and the creation-date of an _instance_ of a file.

When it comes to digital files, what is the difference
between a copy of the original and that of the original
copy? .. i mean except for the different creation dates of
the file-instances.

I'm still assuming it's the date the file was compiled: the
compiled date stamp. Subsequent *identical* copies of it
(and their new dates (if any) would seem to be of little use,
as long as the code was identical to when it was first
compiled.

Look at the majority of files in %WinDir%\System\, the ones that
have a modification-date of 1998-1999 of the original Win98xE.
The files were obviously created/compiled at that date or
earlier, but on your machine they will have the creation-date of
what your computers clock were set at when you installed windows.
IOW, the creation-dates of that particular instance of the files.



For example, if some DLL file has a creation date of 12/2004,
then who cares about the dates of any newer copies *so long as
the file contains the originally compiled code of 12/2004* -
meaning no changes or revisions were made to it.


It seems that the people that creates the file-systems,
operating-system, copy-routines and file-transfer protocols
thinks that the creation-date of a particular instance of a file
that is what is important (for the most part).

Me, i'd like there to be provisions to see two (different)
creation-dates for each file.


--

FromTheRafters wrote:

Etal wrote:

FromTheRafters wrote:

legg wrote:


You'd think so, wouldn't you. In fact the create date is
the date the file/rev is placed on the disc.

Technically, it (the file) isn't placed on the disk. The
terminology is actually good. The *file* is "created" on
the disk and the content of the remote file (the program,
document, or whatever) is transferred to that newly
created file. There is sometimes a way to retain the
source's 'file creation date' with some protocols - the
just modify the creation date to match the source.

The terminology used is actually insufficient. It doesn't
(allow to) differentiate between the creation-date of a file
and the creation-date of an _instance_ of a file.

The "file" doesn't matter. The file is created by the
filesystem, *not* the programmer. The programmer created the
content that was stored in the file. It's like throwing out
all of your cookies because the the cookie jar your
grandmother gave you is so old.

Whether you look at it as the container or as the content doesn't
matter. The fact is that the creation-date shown when you look at
a files property in Windows it is the creation-date of that
instance of the container/content.


When it comes to digital files, what is the difference
between a copy of the original and that of the original
copy? .. i mean except for the different creation dates of
the file-instances.

No difference, and that is the point. You put your cookies in
a new jar, and they are still the same old cookies. Creation
date and modification date are filesystem artifacts - compile
date (for executables) tells you when the author compiled the
program - it is not a filesystem thing.


Yes, just like you wrote in a previous post:


The "program" creation date might be inside the resource
section - the date it was compiled.


This is something you can find out for files of a select few
file-types, but not for the vast majority of files of different
kinds. Look at Bill-in-Co's followup to my post and see which one
he thinks it is important to know and assumes that it is that is
show as the creation-date for any file.

So to be able to know that date for all files, that's why i said
that the terminology (and the reality of a property-page) ought
to provide for two creation-dates to be given for each file; one
instance-dependent that differs for each particular instance
(like you see today), and one constant instance-oblivious
creation-date for the original creation (of the
container/content). And no, the latter is not the same thing as
the modification date.


--