AHK installer under Linux/WINE

[Drugwash]

Long story short: the (relatively) new installer for the 1.1 flavor of AHK complains about a missing icon in appwiz.cpl on line #4 of the script and then bails out completely, when launched in Linux (Mint 17.2) under WINE (2.0 RC1). Could we get rid of such unnecessary dependencies?
I previously had AHK Basic installed there and it had not complained about anything at install time as far as I can recall.

Unrelated: if anyone here has a fair amount of experience running AHK scripts under Linux (Mint/Ubuntu/Debian) with WINE please contact me, I'd have a few questions to ask.

Thank you.

[just me]

I don't think that you'll find any statement saying that AHK or the installer is designed to run on Linux. So why do you post in the bug section?

[nnnik]

Still it would be a great advantage for it to be able to run under WINE.
As far as I know a few people are running AutoHotkey under Linux. However I don't think they used the standard Installer.

[lexikos]

Get the zip download.

If you want to use the installer, edit Installer.ahk. Adding try before Menu Tray, Icon, appwiz.cpl, -1500 is probably sufficient to remove the icon dependency. If you tell me it works, I'll update the installer in the next release. (Only because this is a very trivial change which won't affect the installer on Windows in any way.)

[Drugwash]

If I add 'try' or just comment out the icon I get "Setup encountered an error. Specifically: 0x800A1391" then asking if I want to install with default options (available Yes, No, Cancel). Note I already have 1.1.24.03 installed by unpacking the zip.
If I click 'Yes' I get a sharing violation (Error installing file AutoHotkey.exe), most likely due to the fact that it's already in use while running installer.ahk.

Thing is, the installer should just do its job deploying the required files; the rest is up to the WINE installation.

As long as the AHK Basic installer worked without problems it would be logical for the new version to follow suit. When it doesn't, it's a bug (at least from my point of view). Whatever happens afterwards in a Linux environment is up to the user.

I have at least one (compiled) script that is being run by a friend of mine under Linux and he's having some troubles. I'm trying to debug the script under my own Linux machine. We do accept a less than 100% functionality but let's fix what can be fixed, shall we.

[lexikos]

I'm not surprised.

AutoHotkey and its installer are built exclusively for Windows (2000 and later), and depend on components that are common to all Windows systems. WINE is not Windows.

Whatever happens afterwards in a Linux environment is up to the user.

Why do you think this doesn't apply to the installer? The installer is a program designed for Windows. You are attempting to use a program on a system it was not designed for, so you must assume all responsibility for the problems that you inevitably encounter.

I would guess that error 0x800A1391 arises because WINE's implementation of the WebBrowser control, which is used for the GUI, is incomplete or faulty.

You shouldn't be using "AutoHotkey.exe" to run the script; it isn't even included in the zip package. Run the script with AutoHotkeyU32.exe. If it still gets a sharing violation, that's probably a fault with WINE or an incompatibility with the underlying Linux file system.

... but let's fix what can be fixed, shall we.

Go ahead, then. What's stopping you?

[Drugwash]

WINE asked for Mono and Gecko installations for .NET and browser compatiblity respectively and I installed both.

I've copied over the 32bit Unicode executable from the zip and renamed it to AutoHotkey.exe. So there shouldn't be any problem with that. But it's logical to get a sharing violation trying to install over an in-use executable.

As I said above, the AHK Basic package installed flawlessly some time ago when I first started some tests so why wouldn't the current version do the same?
Fixing the installer for an official broad usage is not my job since I'm not the maintainer. Why are we at odds, I wonder… The fix you came up with would most likely work on a regular installation and if you want a specific icon then try an embedded one. Can't we just try to live with each-other regardless of how different the worlds may seem? I like "live and let live".

[guest3456]

As I said above, the AHK Basic package installed flawlessly some time ago when I first started some tests so why wouldn't the current version do the same?

because AHK Basic used a completely different installer package

Fixing the installer for an official broad usage is not my job since I'm not the maintainer. Why are we at odds, I wonder…

wonder no more, i'll explain it to you:

the maintainer donates his time for free on this open source project. this is not his 'job' either. therefore, he chooses what he spends his time working on. open source projects are open source for a reason: so that others who want features can also add them and merge them into the main distribution. go ahead and be part of the open source community and contribute your time and resources (like others have done: HotKeyIt, fincs, etc), instead of being a leech who just demands free work from others. of course if i'm wrong, i'm sure lexikos will tell us

I like "live and let live".

you're not "letting" anyone live. "live and let live" would be this: allowing lexikos do add this for you if he chooses to. instead, you're demanding work be done for no one else's benefit but your own. if you don't want to do it yourself, hire someone, including lexikos. and dont look at me, you couldn't pay me enough to waste my time on such a problem. would have to be multiple hundreds per hour before i even blinked at such a request. yet you want someone to do it for free

on that note, a project that i follow (NeoVIM) uses https://www.bountysource.com/ to support the developers. perhaps open a bounty

[nnnik]

WINE asked for Mono and Gecko installations for .NET and browser compatiblity respectively and I installed both.

I highly doubt that this installed the Internet Explorer COM Object

I've copied over the 32bit Unicode executable from the zip and renamed it to AutoHotkey.exe. So there shouldn't be any problem with that. But it's logical to get a sharing violation trying to install over an in-use executable.

First you say there is no problem then you say there is a problem what is it? Shouldn't you have simply named it AutoHotkey32U.exe in order not to get a sharing violation?

[Drugwash]

because AHK Basic used a completely different installer package

Precisely: a package that works fine in both Windows and Linux/WINE. Why the performance degradation now?

[…] the maintainer donates his time for free on this open source project […] go ahead and be part of the open source community […] instead of being a leech […]

I've been doing this on and off since 2008, in case you didn't know. Went through 3-4 forum revamps, community split/rejoin and so on. I've done what I could do and still doing it despite the fact that for all this time I've been ridiculed and bashed for choosing to work primarily with Windows 98SE instead of the "modern" versions. So please don't give me that "don't be a leech" speech. Take a look at the repository in my signature, that's just part of what I've been creating and offering for free, just like anyone here.

I highly doubt that this installed the Internet Explorer COM Object

I'll have to check on that. Maybe WINE already has it built-in, maybe not. I'm very new to Linux myself and only using that machine rarely, for testing purposes, so I don't know the internals. But why would an installer need such thing?

First you say there is no problem then you say there is a problem what is it? Shouldn't you have simply named it AutoHotkey32U.exe in order not to get a sharing violation?

Things got mixed up trying to explain. I meant there was no problem with manually unpacking, copying over and renaming the executable to be in line with all configurations done by the previous (Basic) installer. The problem came when I launched the installer script, possibly because it was using the very executable it was meant to replace. Or not. Indeed I should've added a copy of the Unicode exe without renaming it and launch the script through that one. I was very tired at the time, after a whole day spent trying to debug things. I'll try to check everything thoroughly and report back.

[lexikos]

As I said, you were using the installer script incorrectly. No, you should not have "copied the file over" with or without renaming it. The installer does all copying. Just extract the files to a temporary directory and run Installer.ahk using AutoHotkeyU32.exe (this is all the main exe download does).

Fixing the installer for an official broad usage is not my job since I'm not the maintainer.

This isn't "an official broad usage". It is an unofficial and unsupported, niche usage.

As the only one here (in this thread) who is apparently interested in using AutoHotkey on Linux, you are the more suitable man for the job. If you don't want to do it, that's your prerogative; but don't expect someone else to do it for you.

This is not my job. My job often involves doing things I don't want to do or am not interested in, but it is a regular source of income.

Running AutoHotkey or its installer on Linux is outside the scope of the project. If it was a commercial project, it would be outside the scope of work. So it still wouldn't be my job.

I've done what I could do and still doing it despite the fact that for all this time I've been ridiculed and bashed for choosing to work primarily with Windows 98SE instead of the "modern" versions. So please don't give me that "don't be a leech" speech. Take a look at the repository in my signature, that's just part of what I've been creating and offering for free, just like anyone here.

Did you write your scripts because it was your job, because you purely wanted to "contribute to the community", or because you enjoyed it and/or had use for those scripts?

[Drugwash]

OK, I'll take it from scratch:
- me using Linux stems purely from the desire to help a good friend which is using one of my scripts in such environment with poor results
- since AHK Basic was originally installed, I unpacked the new one over in order to be able to modify and test the installer, since it obviously wouldn't have run under Basic
- having commented out the icon line there popped the new error which I presumed to be due to the exe being in use but probably was something else (lack of COM Object as nnnik said - haven't retried yet)
- when I said 'job' and 'official' I was referring to me not being part of the team that works on the AHK code - installer included - so I wouldn't be allowed to modify the installer code and put it in the official package
- I have been jobless almost all my life, you wouldn't want to be in my shoes, yet I never asked for anything in return for my scripts; I wrote them because I like to create and share with the world, because I needed something that did not exist or was commercial and couldn't afford it, because other people needed them… I may not have agreed to some changes required by others but I did it for them.

I wonder what happened to this community - we used to help each-other out, not argue over semantics or other minor things.
Or maybe that was all in my head…

[just me]

... we used to help each-other out ...

If you want help, why didn't you post in "Ask For Help"? Instead, you stated a bug and claimed that someone has to fix it.

The 'installer' is an AHK script and every error occurring when running it will also occur for every other script using the features causing the error. It isn't 'a bug in the AHK installer. Obviously, it's a bug in WINE/Mono.

Did you look at the command line switches available for the installer?

[Drugwash]

It may not be a code bug but it's a functionality bug. Is there a specific forum section for things that fall in some grey area? We debate where to write about this or that and the fact itself falls under: original installer used to work even in WINE, this one doesn't. That's the fact that I'm trying to bring to attention but obviously it has no importance because I am the only one trying to use it under such circumstances. Maybe if it were somebody else…

In regard to those switches, it may be my lack of knowledge but the only way I know of to actually launch a Windows executable under Linux is to right-click it and choose 'Open with WINE' (or whatever it's called), otherwise some exe unpacker will kick in and one gets to see the internals of the file instead (I'm using Krusader as file manager because I'm too used to Total Commander in Windows). Therefore I don't know how to pass commandline switches to a Windows executable in Linux. And definitely other Linux users may have no idea about this possibility.

Anyway, I get it: "if you want something done, do it yourself". So I'll probably devise my own installer in AHK Basic or just NSIS, wrap AHK package files in it and advertise it somewhere as the proper package for "unusual" usage. Or maybe I'll just learn Linux and make a .deb package directly since I've already read such requests around.

Thank you all - a kick in the butt is a step ahead, isn't it?

[just me]

... and the fact itself falls under: original installer used to work even in WINE, this one doesn't. ...

The last version of the 'original installer' was created in September 2009 at the latest.

[just me]

Therefore I don't know how to pass commandline switches to a Windows executable in Linux.

How to install and run Windows programs

Also, lexikos already added try Menu Tray, Icon, appwiz.cpl, -1500 to the installer in 1.1.24.04.

[guest3456]

So I'll probably devise my own installer in AHK Basic or just NSIS, wrap AHK package files in it and advertise it somewhere as the proper package for "unusual" usage. Or maybe I'll just learn Linux and make a .deb package directly since I've already read such requests around.

Thank you all - a kick in the butt is a step ahead, isn't it?

[Drugwash]

Just to fulfil the promise of returning with details:
I've reinstalled AHK Basic just to make sure I wasn't lying about it installing flawlessly. So it did. And while at that I noticed it's using NSIS 2.26. Why NSIS was abandoned in favor of ActiveX/JS-based script beats me.
Anyway, after hunting for more details on the WineHQ site I found instructions on how to get useful debugging info. Apparently launching the application through wine in a terminal provides useful information. Here you are the output from an installation attempt:

Spoiler

Code: Select all

drugwash@MintCinnamon17-2 ~/Downloads $ wine AutoHotkey_1.1.24.04_setup.exe
fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub
fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub
fixme:atl:AtlAxWinInit version 0300 semi-stub
fixme:ieframe:PersistStreamInit_InitNew (0x167c70)
fixme:atl:OleClientSite_ShowObject (0x167e00) - stub
err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
fixme:iphlpapi:NotifyIpInterfaceChange (family 0, callback 0x6a0cb608, context 0x5268440, init_notify 0, handle 0x609e7b4): stub
fixme:imm:ImmGetDescriptionW (0x4090409, (nil), 0): semi stub
fixme:imm:ImmGetDescriptionW (0x4090409, 0x85452b0, 9): semi stub
fixme:imm:ImmGetOpenStatus (0xdac558): semi-stub
fixme:imm:ImmReleaseContext (0x20098, 0xdac558): stub
fixme:ntdll:NtLockFile I/O completion on lock not implemented yet
fixme:ieframe:BrowserService_GetTravelLog 0x1820a0 0x8d94cc
fixme:ieframe:ClientSite_GetContainer (0x167d3c)->(0x8d94ac)
fixme:mshtml:nsChannel_GetContentDisposition (0xdb5498)->(0x8d8c58)
fixme:mshtml:nsChannel_GetContentDispositionHeader (0xdb5498)->(0x8d83ac)
fixme:ieframe:ClientSite_GetContainer (0x167d3c)->(0x8da34c)
fixme:win:EnumDisplayDevicesW ((null),0,0x8d9974,0x00000000), stub!
fixme:ieframe:DocHostUIHandler_GetDropTarget (0x167d3c)
fixme:ntdll:EtwRegisterTraceGuidsW (0x69edfc08, 0x8542780, {509962e0-406b-46f4-99ba-5a009f8d2225}, 3, 0x9c4e3b0, (null), (null), 0x85427b0): stub
fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {a3da04e0-57d7-482a-a1c1-61da5f95bacb}
fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {917b96b1-ecad-4dab-a760-8d49027748ae}
fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {26d1e091-0ae7-4f49-a554-4214445c505c}
fixme:mountmgr:harddisk_ioctl Unsupported ioctl 2d1400 (device=2d access=0 func=500 method=0)
fixme:mountmgr:harddisk_ioctl Unsupported ioctl 2d1400 (device=2d access=0 func=500 method=0)
fixme:mountmgr:harddisk_ioctl Unsupported ioctl 2d1400 (device=2d access=0 func=500 method=0)
fixme:ieframe:PropertyNotifySink_OnChanged unimplemented dispid 1005
fixme:mshtml:CustomDoc_QueryInterface Unimplemented interface {619f7e25-6d89-4eb4-b2fb-18e7c73c0ea6}
fixme:mshtml:CustomDoc_QueryInterface Unimplemented interface {619f7e25-6d89-4eb4-b2fb-18e7c73c0ea6}
fixme:jscript:JScriptProperty_SetProperty Unimplemented property 70000001
fixme:jscript:JScriptProperty_SetProperty Unimplemented property 70000002
fixme:mshtml:set_event_handler_disp unimplemented event L"dragstart"
fixme:mshtml:CustomDoc_QueryInterface Unimplemented interface {619f7e25-6d89-4eb4-b2fb-18e7c73c0ea6}
fixme:ieframe:PropertyNotifySink_OnChanged unimplemented dispid 1005
fixme:mshtml:CustomDoc_QueryInterface Unimplemented interface {619f7e25-6d89-4eb4-b2fb-18e7c73c0ea6}

So apparently the installer tries hard to use exactly the things that are not implemented in WINE. Ain't that a coincidence…
However, despite that error (not the icon, the other one - I'd provide a screenshot but can't attach any image to this board since forever) the installer still provides the ability to install with default options through that message box. Too bad it chooses the ANSI version when it detects the old Basic version was already installed; could have provided an extra dialog to choose between ANSI and Unicode, considering the compatibility mode in WINE is set for XP. But it's something rather than nothing, isn't it.

My apologies for wasting your precious time, all of you.

[guest3456]

Why NSIS was abandoned in favor of ActiveX/JS-based script beats me.

thats a good question, but probably only Lexikos knows the answer

[lexikos]

The original installer installed one version of AutoHotkey, with only a couple of basic yes/no options.

The current installer does a lot more. The combination of AutoHotkey and HTML/JavaScript makes the installer much easier to extend than the old NSIS one.

• This was probably the main reason for the new installer (it's been a few years):
  Provides different options depending on what was installed (nothing, Basic, v1.1.x or the exact same version). For upgrades from Basic, it provides a warning note and a link to the compatibility documentation.
• Automatically closes and/or reloads scripts if needed.
• Checks for updates automatically and provides a one-click option to download and install the update.
• Other small tweaks, such as adding "Run as administrator" for scripts if UAC is enabled.
• The same setup script can be used to change options without reinstalling.
• Some other things.

- me using Linux stems purely from the desire to help a good friend which is using one of my scripts in such environment with poor results

Perhaps you don't have much motivation to "fix" the installer for Linux yourself, but I have even less.

- having commented out the icon line there popped the new error which I presumed to be due to the exe being in use

I'm sure it was, if the file you were using to run the script is one that the installer was trying to replace.

- when I said 'job' and 'official' I was referring to me not being part of the team that works on the AHK code - installer included - so I wouldn't be allowed to modify the installer code and put it in the official package

I'm not part of any team. Aside from Chris, everyone else who has contributed code or documentation has done so without "write access" to the official package, usually via GitHub. Publishing the installer is only one very small part of the process, and is the only part that you can't do (unless publishing it elsewhere is sufficient, in which case you can do it).

I wrote them because I like to create and share with the world, because I needed something that did not exist or was commercial and couldn't afford it, because other people needed them…

If you didn't enjoy doing it and didn't have any need yourself, would you have done it?

If you're inclined to make any changes to Installer.ahk (which is actually the result of a little pre-processing), the source code is here: https://github.com/lexikos/AutoHotkey-Release