http + ftp download plug-in

Originally Posted by negativesir View Post

Yes, this has to do with WM_INITDIALOG not returning false.

From MSDN:


Here is the fix for it, compiled in Visual C++ 6.0, tested on Windows 95.

Thanks, negativesir. I've verified that this fixes the issue with stealing focus and otherwise works unaltered. I wasn't sure if you'd compiled as release or debug back when you'd submitted this, so I recompiled it using a clean VC++6 under a clean Windows XP of release builds of both ANSI and Unicode just to be sure. It's now been updated on the inetc plugin download page.

Originally Posted by negativesir View Post

Here is the fix for it, compiled in Visual C++ 6.0, tested on Windows 95.

Thanks, negativesir! I've verified that this fixes the issues with stealing focus when in silent mode and does not affect other functionality. (for the curious an Abort was switched to return false where appropriate). I wasn't sure if you'd compiled as release or debug last year, so I recompiled using a clean VC++6 install on a clean Windows XP VM of the release config of both ANSI and Unicode. I've packaged it and updated the default download on the inetc plugins page.

New version:

1.0.4.4 - 20th July 2014
* /tostack & /tostackconv added
* Version information resource added
* Updated to NSIS 3.0 plugin API
* Upgraded to Visual Studio 2012
* 64-bit build added
* MSVCRT dependency removed

Stu

Re - 1.0.4.4: With the update to the NSIS 3.0 beta plugin API, does it still function the same for both NSIS Stable and NSIS Unicode?

Originally Posted by CritterNYC View Post

Re - 1.0.4.4: With the update to the NSIS 3.0 beta plugin API, does it still function the same for both NSIS Stable and NSIS Unicode?

The plugin API has not changed since v2.43 so I'm not sure what Stu means by that comment.

Sorry that change is misleading. The plug-in was using an old copy of exdll.h (with no myato* etc.). The actual API implementation hasn't changed; I have just updated the plugin API source code from latest.

Stu

Oh, so, I understand, thank you, that helped me a lot, thank you very much

------------------------------------------------------------------------

Thank you very much!

etui xperia z2

Thanks for the update, the /tostack flag is very useful. However, using the latest version of the plugin results in a lot of false positives from Antivirus software. Not a huge issue for me, just a heads up.

Update: the latest inetc.dll file is only being marked as a virus by Symantec. I contacted them and they whitelisted it in the latest definitions. But when you actively use the the plugin in your installer you seem to get a lot more false positives. (TrendMicro, VBA32, Kaspesky etc.)

inetc - SendRequest Error - while accessing HTTPS URL

Hello,

I am trying to acces on HTTPS URL. I am getting "SendRequest Error".

I found one StackOverflow link.

This answer says set some flags and I have know idea how to do that 😕

Does anybody know how to do this?

Regards,
Ganesh

The StackOverFlow link is talking about that because the user is using a self-signed certificate. AKA, not from a certificate authority. As such, it'll be rejected and result in an error. If you're using a self-signed certificate, INETC won't work for you in its current form.

inetc failing and showing it's parameters in the stack

Hello,

I'm having a very weird problem with inetc::get that looks like a bug.
A very specific subset of our users are complaining that our installer doesn't work.

What's happening is that inetc::get is failing and it shows in the stack one of it's parameters.
For example, see the code below:

inetc::get /nocancel /translate "Downloading %s" "Connecting ..." second minute hour s "Checking version..." "" /caption " " "http://www.myserver.com/version.xml" "${UPDATES_DIR}\version.xml" /end
Pop $1

inetc::get /translate "Downloading %s" "Connecting ..." second minute hour s "Checking version..." "" /caption " " "http://www.myserver.com/version.xml" "$TEMP\version.xml" /end
Pop $2

inetc::get /noproxy /translate "Downloading %s" "Connecting ..." second minute hour s "Checking version..." "" /caption " " "http://www.myserver.com/version.xml" "${UPDATES_DIR}\version.xml" /end
Pop $3

inetc::get /noproxy /translate "Downloading %s" "Connecting ..." second minute hour s "Checking version..." "" /caption " " "https://www.myserver.com/version.xml" "${UPDATES_DIR}\version.xml" /end
Pop $4

inetc::get "https://www.myserver.com/version.xml" "${UPDATES_DIR}\version.xml" /end
Pop $5

MessageBox MB_OK "normal: $1 --> temp: $2 --> noproxy: $3 --> https: $4 --> noparams: $5 "


The result for this code is:

normal: /nocancel --> temp: /translate --> noproxy: /noproxy --> https: /noproxy --> noparams: https://www.myserver.com/version.xml

So, no matter the call, the error is always the first parameter used.
This doesn't happen with all users, and I haven't figured out what's so specific for those that get the error.

Can you please enlighten me? Is this a bug, or am I missing something?

Thanks!

JS

Do you know what Windows version they are using?

Stu

I asked one of the users, and he's on Windows 7 professional x64 .

He stated also that he's not behind a proxy and he's using Bitdefender Plus 2015.

Does this help?

inetc:😛ut ignores supplied "Content-type" parameters

I am using Inetc to make some REST calls to a local Geoserver instance. I noticed that when performing an inetc:: put and supplying a header for content-type, that header is replaced with "Content-type octet-stream".

In other words, Inetc always assumes that I'm uploading a binary file; it will not let me do a put with something that isn't binary. I need to set the Content-type to something other than "octet-stream", and it doesn't seem like it can be done with the current implementation of Inetc.

I wrote a stackoverflow post on this issue and we were able to confirm what I've said in the source code. If the author is available to implement a fix, it would save me the trouble of having to call out to cURL or something to perform this portion of my install. I'd much rather use Inetc 🙂

Thank you 🙂

Hello,

on the 27th of November, I reported an issue with inetc::get . From that moment on, we've been having more and more users complaining that they cannot use the installer. The error they get is exactly what I reported here - http://forums.winamp.com/showpost.ph...&postcount=493
Can you please help me on this one? I don't really know what to do...

Thanks!

Which version of the plug-in are you using? If you are using the latest, try an older one (the older builds were built using VC6).



Stu

Originally Posted by apastel View Post

I am using Inetc to make some REST calls to a local Geoserver instance. I noticed that when performing an inetc:: put and supplying a header for content-type, that header is replaced with "Content-type octet-stream".

In other words, Inetc always assumes that I'm uploading a binary file; it will not let me do a put with something that isn't binary. I need to set the Content-type to something other than "octet-stream", and it doesn't seem like it can be done with the current implementation of Inetc.

I wrote a stackoverflow post on this issue and we were able to confirm what I've said in the source code. If the author is available to implement a fix, it would save me the trouble of having to call out to cURL or something to perform this portion of my install. I'd much rather use Inetc 🙂

Thank you 🙂

So rather than replacing the existing header, you would like it to add only if it does not exist?

Stu

Hi Stu,

thanks for the tip! Unfortunately it didn't work. Here's more info:

• I compiled the installer with the build from 04:29, 20 August 2013
• Asked one of the users who reported the issue to test it
• He had the same problem I reported above - $1, $2, $3, etc are getting the parameters sent to inetc instead of the result of the call
• I asked him to try "running as administrator", and guess what... It worked fine!

Does this info provides any clue on what's happening?

Thanks!

JS

Try building with the NSIS logging special build (you need to add LogSet on to your script). It sounds to me like the plug-in cannot be loaded under the original user for some reason.

Stu

Hi Stu,

thanks for the help.
I've sent the debug build to the client (with inetc from 04:29, 20 August 2013), who returned the results below.
It seems inetc.dll cannot be loaded. Any suggestions?

Starting Logger
CreateDirectory: "C:\Users\Hugo\AppData\Roaming\com.boonzi.desktop\Local Store\updates" (0)
Call: 152
File: overwriteflag=1, allowskipfilesflag=2, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: wrote 20992 to "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
Call: 152
File: overwriteflag=1, allowskipfilesflag=0, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: skipped: "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll" (overwriteflag=1)
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
Call: 152
File: overwriteflag=1, allowskipfilesflag=0, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: skipped: "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll" (overwriteflag=1)
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
Call: 152
File: overwriteflag=1, allowskipfilesflag=0, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: skipped: "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll" (overwriteflag=1)
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
Call: 152
File: overwriteflag=1, allowskipfilesflag=0, name="C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll"
File: skipped: "C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll" (overwriteflag=1)
Error registering DLL: Could not load C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll
MessageBox: 0,"normal: /nocancel --> temp: /translate --> noproxy: /noproxy --> https: /noproxy --> noparams: https://www.boonzi.com/server/releases/update "
MessageBox: 0,"Por favor, envie o ficheiro install.log para support@boonzi.com . Clique OK para abrir a pasta"
ExecShell: success ("open": file:"C:\Users\Hugo\AppData\Roaming\com.boonzi.desktop\app" params:"")
Delete: DeleteFile("C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\inetc.dll")
Delete: DeleteFile("C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\modern-header.bmp")
RMDir: RemoveDirectory("C:\Users\Hugo\AppData\Local\Temp\nssA7C5.tmp\")

You should use Dependency Walker and open inetc.dll on the machine and check all the referenced DLLs exist. Also ask if they are using any antivirus or antimalware software which may be blocking the DLL.

Stu

Hi Stu,

thanks once again for the answer.
Most of these concepts are pretty new for me, so let's see if I understood correctly your suggestion:

1- I have to ask the end-user (with the problem) to download http://www.dependencywalker.com/
2- I have to send him the inetc.dll
3- I assume the dependency walker will return some kind of logging, that I have to ask the client to return to me, so I can paste it here.

Did I understand correctly?


Some of clients who had this issue had an anti-virus, but not all. Let me know if I got the steps right, so I can go forward and ask one of the users to try it out.

Thanks,

JS

Dependency walker should popup a messagebox when you open a dll if there is a problem. It also has a log window at the bottom that you should ask the user to copy, ignore warnings with "delay-load" in them...

inetc doesn't validate SSL certificates

Any application that uses inetc to download things from the internet can be attacked using man-in-the-middle (MITM) techniques. When inetc retrieves something over an https:// URI, the certificate is ignored, meaning that it could be downloading files from anywhere. The security impact of this goes as high as arbitrary code execution with administrative privileges.

Originally Posted by wd1 View Post

Any application that uses inetc to download things from the internet can be attacked using man-in-the-middle (MITM) techniques. When inetc retrieves something over an https:// URI, the certificate is ignored, meaning that it could be downloading files from anywhere. The security impact of this goes as high as arbitrary code execution with administrative privileges.

This is a good point and it should probably reject those connections by default and allow the script author to override it with a /nosecurity parameter or something like that...

Since sourceforge is down. Can you please post the plugin on this thread. I need it badly...

I checked the google cache, unfortunately the download link is still to sf.net. You can still browse the whole site via the cache.

I'm using the Inetc plugin to download a large 3GB file and it displays a negative percent download. Is there any way I can fix this?