Forum » Feature Requests »

Post a reply

Options
Add an Attachment

If you do not want to add an Attachment to your Post, please leave the Fields blank.

(maximum 10 MB; please compress large files; only common media, archive, text and programming file formats are allowed)

Options

Topic review

AbcdeFghi

Need 64 bit winscp

Hi,

I need 64 bit version for WinSCP, since it doesn't work on Wine, I'm a Mac user and need the WinSCP to transfer some file to servers which only support by WinSCP.

PFB the errors while using Wine. Try to user both Wine and Wine64 still not support. 
19057016@MAC13DQ05FJEN2 winscp553 % wine WinSCP.exe 

zsh: bad CPU type in executable: wine

19057016@MAC13DQ05FJEN2 winscp553 % wine64 WinSCP.exe

0024:err:process:exec_process L"Z:\\Users\\XXXXX\\Documents\\zz_simple_script_zz\\winscp553\\WinSCP.exe" not supported on this system
maysiya

Hello, Does exists a 64 bits WinSCP version?

Hello,
Does exists a 64 bits WinSCP version?
aloishammer

martin wrote:

It's unlikely. I do not have a time to reimplement WinSCP using a different toolkit.

Aw, man. Well, I had to ask. I'd like to help move WinSCP forward; I really prefer it to the other SFTP solutions I have available.

The GSSAPI requirement noted above in the thread is actually also a pretty good reason to try and get a working 64-bit build out; PuTTY / WinSCP do or at least can use a number of third-party libraries. As the greater number of developers move to 64-bit builds, a lot of them are no longer making 32-bit GSSAPI (and other) libraries available, because it's extra effort and they don't see a reason to.

Microsoft themselves have already retired 32-bit builds of MAJOR projects, like SQL Server and Exchange Server. It's getting so the only thing left is Windows itself, and that only on the desktop.

In short, WinSCP is becoming less compatible and (comparatively) less secure as other developers retire the i386 architecture for good.
martin

aloishammer wrote:

Martin, is there any chance you'd consider moving to a free-as-in-beer build environment? I pulled down the source to see if I could cajole it into compiling against a Win64 target, but I don't have Embarcadero C++ Builder XE6 Professional. I imagine most people don't. I do have Visual Studio 2015 (because it's free). I didn't bother checking the other requirements.

It's unlikely. I do not have a time to reimplement WinSCP using a different toolkit.

Also, in response to your note above about there not being a good reason to make an x64 build of WinSCP available - Microsoft have been providing Server (optionally) without WoW64 since at least Server 2008 R2. Leaving out WoW64 means significantly lower memory and disk requirements. I would absolutely install Windows without WoW64 if I could get away with it... but I can't, because I need tools like WinSCP that haven't made x64 builds available.

There are some other very good reasons; too many to go into here, but one is that ASLR is crippled on 32-bit systems, in 32-bit subsystems, and in 32-bit binaries. It's not a Windows-only problem, either.

Thanks for this information.
aloishammer

Martin, is there any chance you'd consider moving to a free-as-in-beer build environment? I pulled down the source to see if I could cajole it into compiling against a Win64 target, but I don't have Embarcadero C++ Builder XE6 Professional. I imagine most people don't. I do have Visual Studio 2015 (because it's free). I didn't bother checking the other requirements.

Also, in response to your note above about there not being a good reason to make an x64 build of WinSCP available - Microsoft have been providing Server (optionally) without WoW64 since at least Server 2008 R2. Leaving out WoW64 means significantly lower memory and disk requirements. I would absolutely install Windows without WoW64 if I could get away with it... but I can't, because I need tools like WinSCP that haven't made x64 builds available.

There are some other very good reasons; too many to go into here, but one is that ASLR is crippled on 32-bit systems, in 32-bit subsystems, and in 32-bit binaries. It's not a Windows-only problem, either.
martin

@crystalidea: Sorry, nothing has changed since you have asked the last time.

I do not see any strong use case for the 64-bit version, that would justify the immense work that it requires.
crystalidea

Any progress? PuTTY is now 64-bit
martin

Re: 64bit COM/OLE

@Guest: I do not get this problem. I can load the assembly into 64-bit PowerShell without any problems.
Actually, you probably have this problem:
https://winscp.net/eng/docs/message_net_operation_not_supported
If this does not help, please start a new thread, as your problem is probably not related to this topic.
Guest

Re: 64bit COM/OLE

This is what happens when I run a powershell script using the native 64bit version of PowerShell.exe: 
Microsoft Windows [Version 6.3.9600]

(c) 2013 Microsoft Corporation. All rights reserved.



C:\Windows\system32>\\tpa-isl\ftp\budd\aig_autoftp.bat



C:\Windows\system32>PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '\

\tpa-isl\ftp\budd\WINSCP.ps1'";

Add-Type : Could not load file or assembly

'file:///C:\Windows\system32\WinSCPnet.dll' or one of its dependencies.

Operation is not supported. (Exception from HRESULT: 0x80131515)

At \\tpa-isl\ftp\budd\WINSCP.ps1:1 char:1

+ Add-Type -Path "WinSCPnet.dll" -ErrorAction Stop

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [Add-Type], FileLoadException

    + FullyQualifiedErrorId : System.IO.FileLoadException,Microsoft.PowerShell

   .Commands.AddTypeCommand





New-Object : A positional parameter cannot be found that accepts argument '

    Protocol = [WinSCP.Protocol]::Sftp

    HostName = "prod-mfttpg01"

    UserName = "fteadmin"

    Password = "Qurman98"

    SshHostKeyFingerprint = "ssh-rsa 2048

1d:fc:6c:2b:a8:89:24:13:9b:95:61:99:47:44:e1:26"

                                                              '.

At \\tpa-isl\ftp\budd\WINSCP.ps1:19 char:19

+ $sessionOptions = new-object -ComObject WinSCP.SessionOptions {

+                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidArgument: (:) [New-Object], ParameterBind

   ingException

    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell

   .Commands.NewObjectCommand



New-Object : Cannot find type [WinSCP.Session]: verify that the assembly

containing this type is loaded.

At \\tpa-isl\ftp\budd\WINSCP.ps1:29 char:12

+ $session = New-Object WinSCP.Session

+            ~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidType: (:) [New-Object], PSArgumentExcepti

   on

    + FullyQualifiedErrorId : TypeNotFound,Microsoft.PowerShell.Commands.NewOb

   jectCommand



You cannot call a method on a null-valued expression.

At \\tpa-isl\ftp\budd\WINSCP.ps1:34 char:1

+ $session.SessionLogPath($slog)

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException

    + FullyQualifiedErrorId : InvokeMethodOnNull



You cannot call a method on a null-valued expression.

At \\tpa-isl\ftp\budd\WINSCP.ps1:38 char:1

+ $session.Open($sessionOptions)

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException

    + FullyQualifiedErrorId : InvokeMethodOnNull



New-Object : A positional parameter cannot be found that accepts argument '

    TransferMode = [WinSCP.TransferMode]::Binary

                                                                '.

At \\tpa-isl\ftp\budd\WINSCP.ps1:57 char:20

+ $transferOptions = new-object -ComObject WinSCP.TransferOptions {

+                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidArgument: (:) [New-Object], ParameterBind

   ingException

    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell

   .Commands.NewObjectCommand



New-Object : A positional parameter cannot be found that accepts argument '

    OtherRead = $True

    OtherExecute = $True

    UserRead = $True

    UserWrite = $True

    UserExecute = $True

    GroupRead = $True

    GroupExecute = $True

                                                            '.

At \\tpa-isl\ftp\budd\WINSCP.ps1:75 char:16

+ $permissions = new-object -ComObject WinSCP.FilePermissions {

+                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidArgument: (:) [New-Object], ParameterBind

   ingException

    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell

   .Commands.NewObjectCommand



You cannot call a method on a null-valued expression.

At \\tpa-isl\ftp\budd\WINSCP.ps1:99 char:1

+ $transferResult =

$session.PutFiles("\\tpa-isl\ftp\save\kaiser\DNC_20170214.log" ...

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~

    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException

    + FullyQualifiedErrorId : InvokeMethodOnNull



You cannot call a method on a null-valued expression.

At \\tpa-isl\ftp\budd\WINSCP.ps1:100 char:1

+ $transferResult.Check()

+ ~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException

    + FullyQualifiedErrorId : InvokeMethodOnNull



You cannot call a method on a null-valued expression.

At \\tpa-isl\ftp\budd\WINSCP.ps1:114 char:5

+     $session.Dispose()

+     ~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException

    + FullyQualifiedErrorId : InvokeMethodOnNull





C:\Windows\system32>
martin

@aloishammer: Thanks for this information!
aloishammer

@martin, since no one else has mentioned it: I've had good results compiling PuTTY "beta" and snapshot source with both MSVC++ 2015 Community Edition and the RC of MSVC++ 2017.

There's some minor breakage when compiling against a snapshot: the included VS2012 solution imports fine, but someone forgot that a couple files needed during the resource compile pass aren't in the same directory as the solution, and weren't included in any search path that matches the location of the .RC2s. This can be fixed with a symlink. There is what appears to be a test project or perhaps an unfinished project under the solution that does not build at all, and I haven't tried to make it work. I simply removed it from the solution. The main executable and all the other projects (plink, Pageant, etc.) are tested and working.

The git repo doesn't include the solution files, the InnoSetup installer source, or any other "support" files, which I find bizarre.

I haven't even attempted to compile to x86, since the PuTTY team already provides those snapshot builds. All of my x64-targeted builds have seemed to work perfectly, both out of the box and with extensive modifications to the projects to enable optimization flags. This is also under both the 2015 and the 2017 RC Community Edition environments.

I've been using my own snapshot builds, consisting of about fifteen distinct source snapshots (latest 2017-01-04 or so) for a little over a year.

It would be very nice to see official, native, x64-targeted builds of WinSCP and other highly useful Free and freeware utilities for use on Server environments where the x86 compatibility layer has been removed due to resource constraints or performance considerations.

I don't personally have a need for it, but apparently Microsoft have revived the ARM target (Aarch32 only?) for Windows, so it's likely people are going to start asking for it in the near future. This would be a good time for the PuTTY team and users of PuTTY-derived code to begin the process of ensuring that the code compiles cleanly across multiple architectures in general.

I hope this information about PuTTY compile targets is useful for the WinSCP team.
martin

Re: 64bit COM/OLE

@bmcnish: The winscpnet.dll assembly targets "AnyCPU". So you can use it both in 32-bit and 64-bit environments. We will need more details about your problem to help you.
crystalidea

So, 64-bit version is to be released? :P
bmcnish

64bit COM/OLE

I am working on a 64bit Windows 2012 R2 server and converting old VBS scripts that use the WinSCPnet.dll to transfer files. The issue I come across is that the DLL is 32bit making it impossible to run the converted script outside of C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe. It would really be helpful if this interface was 64bit.
martin

@wasted: Thanks for this information.
wasted

Well, a good use case for me would be using 64bit GSSAPI for login. This is not possible with 32bit application.
Vadim

Very sad

Very sad, Martin, if there will be no 64-version of the product.
lemsky

Hi,
I am a follower of WinSCP and take the opportunity to congratulate you for the work. Now I am migrating to Linux I've tried running WinSCP directly with "wine" on a 64-bit Linux distro (based Debian). The fact is that the .exe file runs WinSCP not be 32 bits. I understand that if the ejeccución 64 WinSCP on Linux would be very easy and will surely be one of the most commonly used SFTP clients.
In any case, congratulations and thanks for the work.
martin

Re: Advantages

@wafflemanx: I suppose you are referring to WinSCP .NET assembly, not WinSCP itself.
While the assembly is made available in binary form for 32 bit only, it should be trivial to download the source code and compile it for 64 bit yourself. But I admit I haven't tested it. Will do.

Added to tracker:
https://winscp.net/tracker/1016

Edit: Actually, I do not get this. WinSCP .NET assembly has platform set to AnyCPU, so it can load as 64-bit into 64-bit process. What particular problems are you having with this?
wafflemanx

Advantages

We use WinSCP with SSIS, since SSIS does not have a Secure FTP component. Since WinSCP is a 32bit app, we need to run the whole SSIS in 32 bit and loads suffer from the performance. It would be beneficial if we could run the whole project in 64bit.
martin

@salamanderuser: It's not as trivial as to just compile it.
salamanderuser

Any plans to compile under x64? Compiler is out.
martin

Re: Unsatisfied due to no native 64 bit support

x64PowerUser wrote:

"Technical constraints" usually means there isn't a programmer that uses the required platform, nor has the expertise to optimize for 64 bit. Since that expertise doesn't exist here, I suppose I'll keep looking.

"Technical contraints" means that the first stable version of 64 bit C++ Builder was released only a month ago.
x64PowerUser

Unsatisfied due to no native 64 bit support

@martin: If properly optimized, a 64 bit application would bring increased speed in processing the scripts that handle downloading large numbers of files from an FTP server. Yes, it requires more memory for these optimizations, but real power users generally have plenty of memory to spare for these things.

I am currently searching for, and willing to pay for a good quality, fast, properly optimized native 64 bit FTP client. I am passing on WinSCP because it does not support 64 bit. I am passing on FileZilla for the same reason. Both are slow when compared to a product like Pragma Fortress, SmartFTP, etc.

"Technical constraints" usually means there isn't a programmer that uses the required platform, nor has the expertise to optimize for 64 bit. Since that expertise doesn't exist here, I suppose I'll keep looking.
martin

We cannot make 64 bit version of WinSCP in near future due to technical constraints.

Anyway, what advantage would 64 bit version bring to you?
Valera

First of all, thank you for the nice product!

But this topic is almost FIVE years old.
Is there any chances to see WinSCP x64?

Thanks!
Jeff

Portable

The best way is use the portable version. Work well.
Nnyan

martin wrote:

There are no plans for that.

Has this changed? It would be nice to get a x64 version of this.
Guest

x64 bit

This totally need to be offered in x64 bit. As one of the better FTP clients I would think skimping on this is wrong.
In fact all programs should be written for 64 bit computers. It doesn't make sense not to. Any program intending to run in an x64 environment should run native. Even if no serious performance benefit is evident, there certainly is a benefit. Function, operation, and integration with the OS software and a few benefits of having it run native. Sure it works as a 32bit app, but it would play nicer as a x64 app on a x64 machine.
martin

Re: 64 bit

@Darrell: You do not have that amount ;-)
Darrell

64 bit

How big a donation would it take to get you to build a 64 bit version that handles SMB shares??
martin

Re: Still getting this error with WinSCP 4.1.8

@daaron: Thanks for your post. This issue has been added to tracker.
Can you provide me your email address, so I can send you a debug version of WinSCP to test this? I do not have a 64-bit system available. If you do not want to post the address here, you can send me an email. You will find my address (if you log in) in my forum profile. Please include link to this topic. Thanks.
daaron

Still getting this error with WinSCP 4.1.8

I'm using WinSCP 4.1.8 on Windows Vista x64, and I get this same error:
WinSCP was not able to detect folder, where the dragged files(s) was dropped. etc.

It appears to work just fine when I drag files from WinSCP to the desktop (a 64-bit process) or to Windows Explorer x64, but when I try to drag files to the 32-bit Windows Explorer (which I use sometimes for compatibility with certain 32-bit Explorer extensions), I get this error.

Is it possible to install both the 32-bit and 64-bit WinSCP Explorer extensions on x64 Windows? (Many other apps do this.)

Thanks,
matze

working on version 3.8.2

Hi,
I've AMD Dual Core & Win XP x64

WinSCP Ver 3.8.2 works fine.

Mfg Matze
webmaster

I need too!
PuTTY dont work on Windows Vista Business 64-bit :(
martin

Re: I third this

Phil wrote:

Drag and drop from 32-bit apps into Windows Explorer doesn't work properly under 64-bit XP. There's something about the 64-bit explorer such that when the item is dragged from WinSCP to an explorer window, a folder entitled (for instance) scp51328 is created in the explorer, and then WinSCP itself complains with the "WinSCP was not able to detect folder, where the dragged file(s) was dropped. Either ...".

I think that's the reason that the TortoiseSVN guys have an x64 version as well as an x86 version.

It should be enough to make 64-bit drag&drop shell extension. It is planned. TortoiseSNV is Explorer-plugin not a regular application.

Anyhow, if you need access or work done on a 64-bit platform, you can get to me from the contact links at www.pagaros.com.au.

Thanks. I will do once I have anything to test.
Phil

Re: I third this

Drag and drop from 32-bit apps into Windows Explorer doesn't work properly under 64-bit XP. There's something about the 64-bit explorer such that when the item is dragged from WinSCP to an explorer window, a folder entitled (for instance) scp51328 is created in the explorer, and then WinSCP itself complains with the
WinSCP was not able to detect folder, where the dragged file(s) was dropped. Either ...

I think that's the reason that the TortoiseSVN guys have an x64 version as well as an x86 version.

Anyhow, if you need access or work done on a 64-bit platform, you can get to me from the contact links at www.pagaros.com.au.
martin

Re: I third this

@cory: What for?
cory

I third this

I need the 64 bit also
martin

There are no plans for that.
Guest

I 2nd this also :P
Artur Lopes Bezerra

64 bits WinSCP version

Hello,
Does exists a 64 bits WinSCP version?
If not, any prevision?
TIA

Documentation

Support

Associations

Follow Us