On 3/24/2012 12:36 PM, Walter Bright wrote:
> On 3/24/2012 12:31 PM, Nick Sabalausky wrote:
>> Windows is known to enjoy holding locks on files just for the fuck of it.
>> See if the behavior changes if you add some delay just before the last line.
>> Or, if you adjust it so that compiling test.d takes longer.
>
> I tried those. No dice.
>

Even running a program in between that does a sleep for a full second does not fix it.

On Sat, 24 Mar 2012 20:48:47 +0100, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/24/2012 12:36 PM, Walter Bright wrote:
>> On 3/24/2012 12:31 PM, Nick Sabalausky wrote:
>>> Windows is known to enjoy holding locks on files just for the fuck of it.
>>> See if the behavior changes if you add some delay just before the last line.
>>> Or, if you adjust it so that compiling test.d takes longer.
>>
>> I tried those. No dice.
>>
>
> Even running a program in between that does a sleep for a full second does not fix it.

You could try Process Explorer or
http://blad.wordpress.com/2006/05/11/fuser-on-win32/
to find out who is locking the file.

On 3/24/2012 12:48 PM, Walter Bright wrote:
> On 3/24/2012 12:36 PM, Walter Bright wrote:
>> On 3/24/2012 12:31 PM, Nick Sabalausky wrote:
>>> Windows is known to enjoy holding locks on files just for the fuck of it.
>>> See if the behavior changes if you add some delay just before the last line.
>>> Or, if you adjust it so that compiling test.d takes longer.
>>
>> I tried those. No dice.
>>
>
> Even running a program in between that does a sleep for a full second does not
> fix it.

Even replacing the sleep program with the bat command PAUSE doesn't fix it. :-(

On 3/24/2012 12:40 PM, Nick Sabalausky wrote:
> If it still fails with the delay, you can probably find out (for whatever
> help it might be) what process is holding the file open by adding a pause
> right after running "test". Then before "Press[ing] a key" as it suggests,
> run SysInternal's Process Explorer to see who has the file open. My guess
> would be some basic Windows system process, but who knows.

It's looking more and more like I cannot migrate to Windows 7. First off, I cannot run any 16 bit code. Second, I cannot run the D test suite.

Bleh.

I'm glad I decided to do Win7 on a separate box rather than "upgrade" my XP box. What a disaster that would have been.

(More info: it isn't core.cpuid, that just increases the likelihood of the failure. Also, looking at the process list when doing a PAUSE shows no new processes, but it still fails.)

On 3/24/12, Walter Bright <newshound2@digitalmars.com> wrote:
> Running the D test suite, I ran into a very strange problem.

I can reproduce the problem on Win7 x64. It doesn't seem to have anything to do with DMD. This is my cc.bat:

dmd -c test.obj
link test.obj
test
link test.obj

But it's not Optlink's fault either. Unilink has the same issue:
dmd -c test.d
ulink test.obj
test.exe
ulink test.obj

C:\dev>cc.bat
C:\dev>dmd -c test.d
C:\dev>ulink test.obj
UniLink v1.07 [beta] (build 3.35)

C:\dev>test.exe
Success

C:\dev>ulink test.obj
UniLink v1.07 [beta] (build 3.35)
Fatal: Unable to create file 'test.exe' (program still running?)

It could be a Win7 x64 bug. If you'll give me 20 minutes I'll get a hold of an x86 Win7 installation and see if I can reproduce the bug there.

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jklc1h$25l6$1@digitalmars.com...
>
> Also, looking at the process list when doing a PAUSE shows no new processes, but it still fails.
>

No, no, first download this, it's like Task Manager on steriods:

http://technet.microsoft.com/en-us/sysinternals/bb896653

You can use that to look up a file and see what process has it open. IIRC, you do "Find" -> "Find Handle or DLL...", type in the filename (in this case "test.exe"), hit the "Search" button, and if the instructions I'm giving you here are actually correct, then it should show you what process is holding "test.exe" open.

On 3/24/2012 2:08 PM, Andrej Mitrovic wrote:
> But it's not Optlink's fault either. Unilink has the same issue:

I did initially suspect Optlink. It's good to know that that is not the problem.

On 3/24/12, Walter Bright <newshound2@digitalmars.com> wrote:
> On 3/24/2012 2:08 PM, Andrej Mitrovic wrote:
>> But it's not Optlink's fault either. Unilink has the same issue:
>
> I did initially suspect Optlink. It's good to know that that is not the problem.
>

In the meantime if you're just building and testing execution of multiple .d files individually you can use a for loop and the -of switch. E.g.:

setlocal EnableDelayedExpansion
For %%a in (*.d) do dmd -of%%~na.exe %%a && %%~na.exe

On 3/24/2012 2:39 PM, Andrej Mitrovic wrote:
> On 3/24/12, Walter Bright<newshound2@digitalmars.com>  wrote:
>> On 3/24/2012 2:08 PM, Andrej Mitrovic wrote:
>>> But it's not Optlink's fault either. Unilink has the same issue:
>>
>> I did initially suspect Optlink. It's good to know that that is not the
>> problem.
>>
>
> In the meantime if you're just building and testing execution of
> multiple .d files individually you can use a for loop and the -of
> switch. E.g.:
>
> setlocal EnableDelayedExpansion
> For %%a in (*.d) do dmd -of%%~na.exe %%a&&  %%~na.exe

Yeah, looks like I'll have to add an iteration count to the exe name.

On 3/24/12, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> It could be a Win7 x64 bug. If you'll give me 20 minutes I'll get a hold of an x86 Win7 installation and see if I can reproduce the bug there.

I can't reproduce this on Win7 x86. I've tried numerous times but it never failed. It seems it's x64-related (or just a Win7 x64 bug).