A
Alan
I guess I'll just leave mine alone for now. Thanks for testing. :>
Alan
Alan
It seems to be some kind of component of XML or other coding
language. I have this module on different OS'es (XP, Server 2003).
There appears to be an instance in the \Application Data subfolder
of the profile and another one in the \Local Settings\ tree.
I was searching around for info and read through a certification for
Visual .Net and it made reference to leaving the .Dat after uninstall.
Whatever it's function, it doesn't seem to get accessed/updated as
both copies on my primary machine have quite old "Last Modified"
time stamps. The module is also found on a Windows 2000 instance.
You would think that the naming convention of
"GDIP" would lend some clue about it - but nothing I could
turn up. This would be a good item for any Microsoft folks
Just as a test case, I renamed the 2 files on my system to a
non-functional extension .org. They are not part of the WFP
(Windows File Protection) as no immediate replacements
were applied. I rebooted and only the .Dat in:
C:\Docs & Settings\'MyProfileName'\Local Settings\Application
Data
was recreated. The other .dat retained it's .Org extension.
Apparently, Windows itself recreates the single .Dat and the
others may not be required/needed by the system.
... et al. said:It seems to be some kind of component of XML or other coding
language. I have this module on different OS'es (XP, Server 2003).
There appears to be an instance in the \Application Data subfolder
of the profile and another one in the \Local Settings\ tree.
I was searching around for info and read through a certification for
Visual .Net and it made reference to leaving the .Dat after uninstall.
Whatever it's function, it doesn't seem to get accessed/updated as
both copies on my primary machine have quite old "Last Modified"
time stamps. The module is also found on a Windows 2000 instance.
I don't run many DotNet dependent programs that i know of, but the two
programs that i know have created [GDIPFontCacheV1.dat]-files for me are
both DotNet Framework dependent:
(%WinDir%\Application Data\GDIPFontCacheV1.dat) by
'Quake II .NET' <http://www.vertigosoftware.com/Quake2.htm>
(Visual C++ with a .NET managed heads-up display - Open Source (¿GPL?))
(%UserProfile%\Local Settings\Application Data\GDIPFontCacheV1.dat) by
'MetMedic' <http://metmedic.dontexist.org/>
(*.vb source files - Open Source (GPL))
Now looking, it seems that my ms Management Console [MMC.exe] is also
DotNet managed, still it doesn't create any [GDIPFontCacheV1.dat] file.
This thus suggests that only a subset of DotNet managed apps do make use
of [GDIPFontCacheV1.dat].
and 'R. McCarty' also wrote [injected from a later post in the thread]:
You would think that the naming convention of
"GDIP" would lend some clue about it - but nothing I could
turn up. This would be a good item for any Microsoft folks
Ehh.., from GDIPlus (GDI+) probably, ¿no?
and 'R. McCarty' also wrote [injected from a later post in the thread]:
Just as a test case, I renamed the 2 files on my system to a
non-functional extension .org. They are not part of the WFP
(Windows File Protection) as no immediate replacements
were applied. I rebooted and only the .Dat in:
C:\Docs & Settings\'MyProfileName'\Local Settings\Application
Data
was recreated. The other .dat retained it's .Org extension.
Apparently, Windows itself recreates the single .Dat and the
others may not be required/needed by the system.
So i suggest you have some DotNet dependent (managed) program running at
bootup. Likewise that the OP, Questioner, runs a DotNet dependent
program quite frequently so that the [GDIPFontCacheV1.dat] "soon" comes
back.
Someone had linked [GDIPFontCacheV1.dat] to 'Hallmark Card Studio'. I
don't know if that uses DotNet or not.
<http://www.hallmarksoftware.com/products/hjw/sys_req.aspx> doesn't say
if it does.
Via other web-links [GDIPFontCacheV1.dat] is thought to have something
to do with Printers (Drivers or software) and i think remember reading
that many of these installs the DotNet framework.
Finally via the web-links i read, i didn't see that 'LinkGrabber99'
specifically uses [GDIPFontCacheV1.dat] for it's malware-activities or
if perhaps it is just an innocent file in a bad context, if perhaps
'LinkGrabber99' is developed in DotNet.
--
Nah-ah. I'm staying out of this. ... Now, here's my observations.
Please followup in the newsgroup.
E-mail address is invalid due to spam-control.