Windows XP - clink_x86 is not a valid win32 application

[aleeksunder]

On Windows XP 32-bit with clink v0.4.3 we get the following system message:

clink_x86 is not a valid win32 application

and clink is not working

[uahim]

I'm getting this too, on my previous installation Clink worked fine.

• dropped support for this OS, e.g. like KODI/XBMC?

[mridgers]

I use Visual Studio to build binaries for Clink now so out-of-the box support for XP's gone. It should still work though so you can build binaries yourself using MinGW or VS2010 should you wish.

[uahim]

I see this is closed, but I'm curious: feature-wise there's no reason to drop support, it's just the compiler that refuses to build proper executables?

[mridgers]

Essentially, yes. I was a bit hasty in closing the issue as VS2013 can actually target XP. I will see how feasible that is.

[uahim]

thanks for looking into it

[akpotter]

Thanks for looking into it, too. Got the same issue.

[michelepagot]

voteUp same issue

[mridgers]

Can someone confirm that this build works on XP?

[uahim]

yes, it does (though installing as autorun does not work, but I guess thats because its "dev"?)

[mridgers]

The autorun should still work. What does "clink autorun --show" display? What happens if you do "clink autorun --install" (you'll need Administrator privileges for this one)?

[uahim]

yes, that's the problem, I should have mentioned that earlier. sorry.

C:\Program Files\clink\DEV>clink autorun -s
native :

when trying to install, despite being logged in as Administrator, it says

C:\Program Files\clink\DEV>clink autorun -i
You must have administator rights to access cmd.exe's autorun

cmd.exe /k clink inject works fine though

[uahim]

just out of curiosity
@mridgers - or maybe somebody else knows - what exactly does clink autorun -i do? maybe it would work if i added it manually to the registry.
thanks

[mridgers]

It modifies the registry entry that cmd.exe reads and executes when it starts up, adding in a clink inject command. From cmd.exe /?;

If /D was NOT specified on the command line, then when CMD.EXE starts, it
looks for the following REG_SZ/REG_EXPAND_SZ registry variables, and if
either or both are present, they are executed first.

    HKEY_LOCAL_MACHINE\Software\Microsoft\Command Processor\AutoRun

        and/or

    HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun

Current builds of Clink only modify the HKLM key which requires Administrator rights to modify. This however is not really correct and was reported in #332 and fixed in 2dd32b1. From this commit clink autorun will default to the per-user HKCU key which does not require elevated privileges (with a --allusers flag added to set HKLM).

[uahim]

@mridgers thank you very much for the detailed explanation and the fix(es)

[CPStagg]

I just installed clink 0.4.5 using the exe installer, to gain the autocomplete functionality in the command line. But this appears to have hosed my visual studio incredibuild builds, which are now peppered with clink_x86 errors. Is there an easy way to back out the install (or at least fix my build functionality)?

Edit:
"Hosed" seems to be an overstatement. It reports numerous errors, but the build and link both appear to work (and execution is unimpaired). It's just that the output is now very messy, full of error reports for operations that were failed with clink_x86. What I want to know is why Incredibuild is getting these errors in the first place. Does it piggyback on cmd.exe functionality which is now doing something else as a result of clink? I don't seem to get the same issues from executing a conventional (non-Incredibuild) compile/link.

[mridgers]

back out the install (or at least fix my build functionality)?

You can use the clink autorun command to remove the entry to start Clink when cmd.exe starts. It shouldn't be injecting itself at all if

What I want to know is why Incredibuild is getting these errors in the first place. Does it piggyback on cmd.exe functionality which is now doing something else as a result of clink?

Clink adds an autorun entry in the registry so it starts when cmd.exe does. It's pretty hard to say what's going on regarding Incredibuild specifically to be honest. Clink checks for a /c on cmd.exe's command line to decide not to install its hooks (the presence of that flag means the session isn't interactive). Maybe Incredibuild doesn't state that and instead uses exit in a Batch script?