martin wrote:

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.

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.

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.

martin wrote:

aloishammer wrote:

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.

Thanks for this information!

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.

crystalidea wrote:

any progress? Putty is now 64-bit

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.

any progress? Putty is now 64-bit

Anonymous wrote:

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)

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.

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>

aloishammer wrote:

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.

Thanks for this information!

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.

bmcnish wrote:

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.

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.

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

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.

wasted wrote:

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

Thanks for this information.

martin wrote:

Sure, I'm aware of these limitations. I believe this is very specific problem that very few users actually face.
I was just wondering, if a new user case emerged that I'm not aware of. Apparently not. Thanks anyway.

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

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

crystalidea wrote:

Modern Windows are all 64-bit.
32-bit version of Altap Salamander has a number of limitation when running on 64-bit Windows. Mostly because of these 2:
1. https://docs.microsoft.com/en-us/windows/desktop/winprog64/registry-redirector
2. https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector
Specially when you're a software developer. I have to keep both version of AS. Very inconvenient.

Sure, I'm aware of these limitations. I believe this is very specific problem that very few users actually face.
I was just wondering, if a new user case emerged that I'm not aware of. Apparently not. Thanks anyway.

martin wrote:

"Salamander 64-bit WinSCP plugin"

Why do you need 64-bit Salamander?

From salamander web site

Running 32-bit Altap Salamander on 64-bit Windows has several drawbacks:
Context menu displayed for files and directories will be different comparing to context menu displayed from Windows Explorer. Reason: 32-bit applications can't load 64-bit shell extensions.

Altap Salamander will show different content for directory %windir%\System32 comparing to Windows Explorer. Reason: part of emulation layer for running 32-bit applications on 64-bit Windows is redirecting access to this directory. See File System Redirector article for more details.

Altap Salamander will show different content for registry key HKEY_LOCAL_MACHINE\Software comparing to Windows Registry Editor. Reason: part of emulation layer for running 32-bit applications on 64-bit Windows is redirecting access to this registry key. See Registry Redirector article for more details.

Modern Windows are all 64-bit.
32-bit version of Altap Salamander has a number of limitation when running on 64-bit Windows. Mostly because of these 2:
1. https://docs.microsoft.com/en-us/windows/desktop/winprog64/registry-redirector
2. https://docs.microsoft.com/en-us/windows/desktop/winprog64/file-system-redirector
Specially when you're a software developer. I have to keep both version of AS. Very inconvenient.

"Salamander 64-bit WinSCP plugin"

Why do you need 64-bit Salamander?

"Salamander 64-bit WinSCP plugin"

crystalidea wrote:

no news? Is it planned actually?

What? WinSCP 64-bit or Salamander 64-bit WinSCP plugin? Both are planned, in a (rather long) term. In this order. No news yet. It's not a priority. Why do you need it?

no news? Is it planned actually?

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.

Is there anyting new regarding 64bit Salamander plugin?

Not yet.

martin wrote:

any news reagrding Slamander 64 bit version?

Not yet.

Is there anyting new regarding 64bit Salamander plugin?

any news reagrding Slamander 64 bit version?

Not yet.

martin wrote:

AArbeit wrote:

The technical constrains mentioned on the Altap website were that the 64bit compiler was not available. This has change some month ago, didn't it ?

When will a 64bit version of the plugin for Altap Salamander available ?

We are going to release stable version of 5.2.x branch in new few days/weeks. Than we will start working on a new branch, for which we plan to upgrade to the latest version of C++ Builder with x64 support. Then we will be able to assess a feasibility of implementing support for x64.

any news reagrding Slamander 64 bit version?
10x
Boby

martin wrote:

wafflemanx wrote:

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

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

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?

+1 Really need it for Altap Samamander as a plugin. Thanks, Martin

AArbeit wrote:

The technical constrains mentioned on the Altap website were that the 64bit compiler was not available. This has change some month ago, didn't it ?

When will a 64bit version of the plugin for Altap Salamander available ?

We are going to release stable version of 5.2.x branch in new few days/weeks. Than we will start working on a new branch, for which we plan to upgrade to the latest version of C++ Builder with x64 support. Then we will be able to assess a feasibility of implementing support for x64.

Hi,

I'm using Altap Salamander on my Windows 7 x64 System every day.

I just bought the WinSCP-plugin on the Altap Website and then noticed, that the plugin doesn't exist in the x64-Version of Altap Salamander :(

I tried to copy the WinSCP plugin from Version 2.54 (32 bit) but Altap Salamander reports that it cannot use 32 bit plugins in a x64 application.

The technical constrains mentioned on the Altap website were that the 64bit compiler was not available. This has change some month ago, didn't it ?

When will a 64bit version of the plugin for Altap Salamander available ?

Thanx for a reply,
Andy

Altap Salamander 3.0 x64 is missing WinSCP!

wafflemanx wrote:

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

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

martin wrote:

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?

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

salamanderuser wrote:

Any plans to compile under x64 ? compiler is out.

It's not as trivial as to just compile it.

Any plans to compile under x64 ? compiler is out.

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.

martin wrote:

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?

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.

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?

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!

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

martin wrote:

There are no plans for that.

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

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.

Darrell wrote:

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

You do not have that amount ;-)

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

daaron wrote:

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 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.

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,

Hi,
is �ve AMD Dual Core & win xp x64

WinScp Ver 3.8.2 works fine.

Mfg Matze

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

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.

martin wrote:

cory wrote:

I need the 64 bit also

What for?

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.

cory wrote:

I need the 64 bit also

What for?

I need the 64 bit also

There are no plans for that.

i 2nd this also :P

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