MinGW - Minimalist GNU for Windows

On Wednesday 23 May 2007 12:18, James Darpinian wrote:
> The workaround of using the syswow64 version of cmd does not fix this
> problem with Vista x64:

Perhaps not unexpected, but this isn't good news.

I don't have a 64-bit machine; neither do I, and fervently hope never to 
have to, use Vista.  I'll have to ask those of you who do, on such a 
machine, to try to resolve this issue and submit patches; if you all 
sit back and wait for someone else to fix it, it won't happen.

Regards,
Keith.

Keith Marshall wrote:
> On Wednesday 23 May 2007 12:18, James Darpinian wrote:
>>The workaround of using the syswow64 version of cmd does not fix this
>>problem with Vista x64:
> 
> Perhaps not unexpected, but this isn't good news.
> 
> I don't have a 64-bit machine; neither do I, and fervently hope never to 
> have to, use Vista.  I'll have to ask those of you who do, on such a 
> machine, to try to resolve this issue and submit patches; if you all 
> sit back and wait for someone else to fix it, it won't happen.

Well, there was this:
http://www.nabble.com/Re%3A-MSYS-and-Vista-64-p9183478.html

Don't know if it's related, though.


-- 
Tuomo

... Cross-country skiing is great in small countries

Tuomo Latto wrote, quoting me:
>> On Wednesday 23 May 2007 12:18, James Darpinian wrote:
>>>The workaround of using the syswow64 version of cmd does not fix this
>>>problem with Vista x64:
>>
>> Perhaps not unexpected, but this isn't good news.
>>
>> I don't have a 64-bit machine; neither do I, and fervently hope never
>> to have to, use Vista.  I'll have to ask those of you who do, on such
>> a machine, to try to resolve this issue and submit patches; if you all
>> sit back and wait for someone else to fix it, it won't happen.
>
> Well, there was this:
> http://www.nabble.com/Re%3A-MSYS-and-Vista-64-p9183478.html
>
> Don't know if it's related, though.

It could be, but there are two problems with it:

1) The patch was never submitted on the patch tracker, so it will most
   likely be overlooked/forgotten.

2) The supplied ChangeLog is incomplete/inappropriately formatted.

Perhaps Oscar Bonilla is reading this; if so, could you please resubmit
that patch on the tracker.

Thanks,
Keith.

Thanks for the response Joel.

Just touching any file, any text file for example.

It works correctly on my home computer but bombs on my work computer.

MS "error signature":
AppName: touch.exe            AppVer: 0.0.0.0    ModName: ntdll.dll
ModVer: 5.1.2600.2180         Offset: 00001230

I'm trying to find out what the difference is but have failed to find it 
yet.
The touch.exe and msys-1.0.dll files are exactly the same (same MD5 and 
SHA-1 sigs).

Arg....

Joe




Joel C. Salomon wrote:
> What invocation is causing the OS to crash?  Are you "touch"ing system
> files, trying to create a file in your home directory, or what?
>
> --Joel
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Mingw-msys mailing list
> Mingw-msys@...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
>
>

On 5/21/07, Joe Flowers <flowers@...> wrote:
> Joel C. Salomon wrote:
> > What invocation is causing the OS to crash?  Are you "touch"ing system
> > files, trying to create a file in your home directory, or what?
>
> Just touching any file, any text file for example.
>
> It works correctly on my home computer but bombs on my work computer.
>
> MS "error signature":
> AppName: touch.exe            AppVer: 0.0.0.0    ModName: ntdll.dll
> ModVer: 5.1.2600.2180         Offset: 00001230
>
> I'm trying to find out what the difference is but have failed to find it
> yet.
> The touch.exe and msys-1.0.dll files are exactly the same (same MD5 and
> SHA-1 sigs).

Any more details about the symptoms of the system crash?

--Joel

-- 
It reverses the normal flow of conversation.
> What's wrong with top-posting?
> > Top-posting.
> > > What's the biggest scourge on plain text email discussions?

Yeah Joel, thanks. For my machine at work, touch.exe does not work 
outside of MSYS either. At home, the exact same at-work MSYS directory 
structure works fine.

I'm still investigating but it looks like they are more dependencies 
showing up in Dependency Walker (http://support.microsoft.com/kb/256872) 
when I "profile" touch.exe on my work machine rather than my home 
machine - and I think that may be the key. There may be anti-virus hooks 
(real-time protection) or something like that that is causing the 
problem. I'll probably disable or un-install my anti-virus program at 
work and reboot to see if that will isolate the problem.

Joe



Joel C. Salomon wrote:
> 
> Any more details about the symptoms of the system crash?
> 
> --Joel
>

I hope this list let's through small attachments; I've attached to JPG 
images.

They are output from Dependency Walker at home and at work, while 
profiling touch.exe.
Notice the verifier.dll and the others below it in the "at-work" image.

Joe


Joe Flowers wrote:
> Yeah Joel, thanks. For my machine at work, touch.exe does not work 
> outside of MSYS either. At home, the exact same at-work MSYS directory 
> structure works fine.
> 
> I'm still investigating but it looks like they are more dependencies 
> showing up in Dependency Walker (http://support.microsoft.com/kb/256872) 
> when I "profile" touch.exe on my work machine rather than my home 
> machine - and I think that may be the key. There may be anti-virus hooks 
> (real-time protection) or something like that that is causing the 
> problem. I'll probably disable or un-install my anti-virus program at 
> work and reboot to see if that will isolate the problem.
> 
> Joe

This fixed it:

C:\WINNT\system32>ren vrfcore.dll vrfcore.dl-
C:\WINNT\system32>ren vfbasics.dll vfbasics.dl-

Joe


Joe Flowers wrote:
> I hope this list let's through small attachments; I've attached to JPG 
> images.
> 
> They are output from Dependency Walker at home and at work, while 
> profiling touch.exe.
> Notice the verifier.dll and the others below it in the "at-work" image.
> 
> Joe
> 
> 
> Joe Flowers wrote:
>> Yeah Joel, thanks. For my machine at work, touch.exe does not work 
>> outside of MSYS either. At home, the exact same at-work MSYS directory 
>> structure works fine.
>>
>> I'm still investigating but it looks like they are more dependencies 
>> showing up in Dependency Walker 
>> (http://support.microsoft.com/kb/256872) when I "profile" touch.exe on 
>> my work machine rather than my home machine - and I think that may be 
>> the key. There may be anti-virus hooks (real-time protection) or 
>> something like that that is causing the problem. I'll probably disable 
>> or un-install my anti-virus program at work and reboot to see if that 
>> will isolate the problem.
>>
>> Joe

On 5/21/07, Joe Flowers <flowers@...> wrote:
> This fixed it:
>
> C:\WINNT\system32>ren vrfcore.dll vrfcore.dl-
> C:\WINNT\system32>ren vfbasics.dll vfbasics.dl-

That this fix worked is almost as disturbing as the fact that touch
was even able to cause a system crash.  Where are these DLLs from?
what are they for?

<After asking Google> vfbasics.dll is part of Microsoft's "Application
Verifier".  There might be a log somewhere that may point out an
actual bug in touch.exe.

--Joel

-- 
It reverses the normal flow of conversation.
> What's wrong with top-posting?
> > Top-posting.
> > > What's the biggest scourge on plain text email discussions?

Joel C. Salomon wrote:
> <After asking Google> vfbasics.dll is part of Microsoft's "Application
> Verifier".  ... may point out an
> actual bug in touch.exe.

These were my thoughts exactly Joel.

Joe

Joe Flowers wrote:
> I hope this list let's through small attachments; I've attached to
> JPG images.

It does, but IIRC, they will not be stored in the list archives.

Regards,
Keith.

Joel C. Salomon wrote:
>> This fixed it:
>>
>> C:\WINNT\system32>ren vrfcore.dll vrfcore.dl-
>> C:\WINNT\system32>ren vfbasics.dll vfbasics.dl-
>
> That this fix worked is almost as disturbing as the fact that touch
> was even able to cause a system crash.  Where are these DLLs from?
> what are they for?
>
> <After asking Google> vfbasics.dll is part of Microsoft's "Application
> Verifier".

On what basis do Microsnot presume to "verify" applications which they
neither provide, nor support?

> There might be a log somewhere that may point out an actual bug
> in touch.exe.

While I don't rule out that possibility, I'd be more inclined to
suspect a bug in the Microsnot rubbish.

Regards,
Keith.

> On what basis do Microsnot presume to "verify" applications which they
> neither provide, nor support?


For example, it is possible for OS programs to tell if there is the 
tiniest buffer over-run, instead of letting some of them slip through.
I have seen this in Netware. I assume MS is doing the same sort of thing 
here.

Joe Flowers wrote, quoting me:
>> On what basis do Microsnot presume to "verify" applications which
>> they neither provide, nor support?
>
> For example, it is possible for OS programs to tell if there is the
> tiniest buffer over-run,

Well, `touch' is a simple enough program.  On a cursory examination
of the source, I can't see where any such flaw might creep in.  You
are welcome to look for yourself:
http://mingw.cvs.sourceforge.net/mingw/msys/packages/coreutils/5.97/

If you can identify a bug, please submit a patch:
https://sourceforge.net/tracker/?group_id=2435&atid=302435

Regards,
Keith.

On May 22, 2007, at 7:53, Joe Flowers wrote:

>> On what basis do Microsnot presume to "verify" applications which  
>> they
>> neither provide, nor support?
>
>
> For example, it is possible for OS programs to tell if there is the
> tiniest buffer over-run, instead of letting some of them slip through.
> I have seen this in Netware. I assume MS is doing the same sort of  
> thing
> here.

Your first sentence is not correct for many C programs.

-g

On Sunday 20 May 2007 01:28, Aaron Gray wrote:
> GIT is looking for /usr/share/git-core/templates but does not seem to
> be able to find it.

Well, there is no reason at all why you cannot create a directory called 
`/usr/share/git-core/templates', (which by virtue of MSYS' automatic 
mounting arrangement would also appear as `/share/git-core/templates').  
However, configuring GIT for installation with a prefix of `/usr/local' 
or `/mingw' rather than '/usr' would be more sensible.

This is particularly true if you are still using MSYS-1.0.10, or 
earlier, rather than the MSYS-1.0.11 development snapshots; if you 
install any GIT executables into `/usr/bin', that really *will* break 
your installation, unless you are building with the MSYS developers' 
compiler suite, and hence making them depend on MSYS-1.0.dll.

Regards,
Keith.

> On Sunday 20 May 2007 01:28, Aaron Gray wrote:
>> GIT is looking for /usr/share/git-core/templates but does not seem to
>> be able to find it.
> 
> Well, there is no reason at all why you cannot create a directory called 
> `/usr/share/git-core/templates', (which by virtue of MSYS' automatic 
> mounting arrangement would also appear as `/share/git-core/templates').  
> However, configuring GIT for installation with a prefix of `/usr/local' 
> or `/mingw' rather than '/usr' would be more sensible.
>
> This is particularly true if you are still using MSYS-1.0.10, or 
> earlier, rather than the MSYS-1.0.11 development snapshots; if you 
> install any GIT executables into `/usr/bin', that really *will* break 
> your installation, unless you are building with the MSYS developers' 
> compiler suite, and hence making them depend on MSYS-1.0.dll.

Yes, tried that, maybe its a "bug" in GIT then.

I will try getting the source rather than using the binary instillation.

Thanks,

Aaron

Aaron Gray wrote, quoting me:
>>> GIT is looking for /usr/share/git-core/templates but does not seem to
>>> be able to find it.
>>
>> Well, there is no reason at all why you cannot create a directory called
>> `/usr/share/git-core/templates', (which by virtue of MSYS' automatic
>> mounting arrangement would also appear as `/share/git-core/templates').
>> However, configuring GIT for installation with a prefix of `/usr/local'
>> or `/mingw' rather than '/usr' would be more sensible.
>>
>> This is particularly true if you are still using MSYS-1.0.10, or
>> earlier, rather than the MSYS-1.0.11 development snapshots; if you
>> install any GIT executables into `/usr/bin', that really *will* break
>> your installation, unless you are building with the MSYS developers'
>> compiler suite, and hence making them depend on MSYS-1.0.dll.
>
> Yes, tried that, maybe its a "bug" in GIT then.
>
> I will try getting the source rather than using the binary instillation.

A binary build, precompiled for MSYS?  Seems kind of implausible.  Where
did you find it?

To run under MSYS, in the absence of an MSYS component build, which we
don't provide, you should be looking for a *native* Woe32 build; that
definitely should not have any precompiled dependency on a UNIX path
such as `/usr/share/git-core/templates' -- it should be in native Woe32
format.  This alone would make me suspect an invalid build, unless of
course it's really a Cygwin build, in which case that's the environment
in which you should be deploying it.

Your best bet, to get it running under MSYS, would be to build from
source, which may involve a (possibly substantial) porting effort.

Regards,
Keith.

>> I will try getting the source rather than using the binary instillation.
> 
> A binary build, precompiled for MSYS?  Seems kind of implausible.  Where
> did you find it?

For MinGW...

Source :-

        http://repo.or.cz/w/git/mingw.git

Binary :-

        http://lilypond.org/git/binaries/mingw/

> To run under MSYS, in the absence of an MSYS component build, which we
> don't provide, you should be looking for a *native* Woe32 build; that
> definitely should not have any precompiled dependency on a UNIX path
> such as `/usr/share/git-core/templates' -- it should be in native Woe32
> format.  This alone would make me suspect an invalid build, unless of
> course it's really a Cygwin build, in which case that's the environment
> in which you should be deploying it.
> 
> Your best bet, to get it running under MSYS, would be to build from
> source, which may involve a (possibly substantial) porting effort.

Aaron

>> A binary build, precompiled for MSYS?  Seems kind of implausible.
>> Where did you find it?
>
> For MinGW...
>
> Source :-
>        http://repo.or.cz/w/git/mingw.git
>
> Binary :-
>        http://lilypond.org/git/binaries/mingw/

Ok, so they look like they should be for native Woe32, and built using
MinGW.  However, neither is an officially supported MinGW package; you
may get more informed support from the respective package maintainers.

Regards,
Keith.