If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#31
|
|||
|
|||
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 |
#32
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help
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." |
#33
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help
System Requirements of Firefox 2.0.0.2032-Bit versions
標indows Vista 標indows XP 標indows Me 標indows 2000 標indows 98 64-Bit Versions 標indows Vista x64 標indows 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 標indows Vista 標indows XP 標indows 2000 64-Bit Versions 標indows Vista x64 標indows XP x64 See not for Windows 98 "MyNews" wrote in message ... "astral" here your fix's http://www.microsoft.com/downloads/e...displaylang=en |
#34
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help
Open have Dragonfly
Makes that FIREFOX look like a childs toy! |
#35
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help
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/ -- |
#36
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help XXX
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/ |
#37
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help
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." |
#38
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help
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. |
#39
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help
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. -- |
#40
|
|||
|
|||
Msvcrt.dll v6.0.9782.0. help
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. -- |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
msvcrt.dll | Jorge | General | 10 | May 12th 05 12:53 AM |
msvcp60.dll and msvcrt.dll | Kyuso Cahi | Setup & Installation | 1 | October 29th 04 03:00 AM |
MSVCRT.DLL | Syed Aslam | General | 9 | September 17th 04 04:50 AM |
msvcrt.dll | Dana | Internet | 1 | September 13th 04 12:29 PM |
MSVCRT.DLL | Cheshire Imp | Setup & Installation | 2 | May 28th 04 03:50 AM |