PDA

View Full Version : ioFTPD 32/64bit


MONGi
03-12-2013, 11:57 AM
Hello,

i have a question for the community.

At the moment run ioFTPD-v7.7.3 + ioNiNJA.1.0.Beta4.2012-10-02 + nxTools-v1.2.1 + nxAutoNuke-v2.5.1, everything is going great so far.
I've noticed over the Taskmanager that probably ioFTPD runs on 32bit (ioFTPD.exe * 32).
Installed on the server, however, is Windows Server 2008 R2 64bit.
Can someone explain me, why the application don`t run unter 64bit?

Thanks.

Greetings,
Mongi

Yil
03-13-2013, 05:06 PM
Applications have to be compiled as either a 64bit or a 32bit executable which determines the size of a memory address among other things. Because the interface to windows passes pointers back and forth a lot this means that there is a hidden layer on 64bit machines that handles emulating a 32bit environment for older apps. On the other hand there are lots of subtle issues with going from 32bit to 64bit for an application that makes such conversions non-trivial if the code wasn't properly written in the first place. It can, and probably would be, a lot of work. I think you'd be surprised by the number of applications that are still 32bit on 64bit machines for that reason alone!

It might be worth the work to compile a 64bit version of ioFTPD for some performance advantages for those who are running 64bit OSs but obviously it wouldn't work on 32bit machines. But it goes beyond that because ioFTPD has dependencies. TCL is the biggest I can think of, but SQLite and OpenSSL are also needed. Today that isn't as big a deal as it would have been like 5 years ago, but I'm not sure 64bit TCL is really all that tested. Things like mySQL, nxTools, etc would all need 64bit support. I'm also not sure if the shared memory interface would get broken. In theory it should be because it uses pointers, but it might be possible to work around that.

Given all that I just don't see going to 64bit as a big priority. 2 releases of everything? Bleck. I've held off on supporting features found only in newer processes for the same reason. I like the fact that ioFTPD runs on really old 386, pentium, and athlon processors. However it might be worth seeing how much of a performance improvement we could get it we target new processors with a separate compile. The good news there is it would still be 32bit so we could re-compile the dependencies easily, but we wouldn't even have to do that if we didn't want to...

MxxCon
03-13-2013, 08:18 PM
I like the fact that ioFTPD runs on really old 386, pentium, and athlon processors.But how many users actually run ioftpd on 386?...even in the last 10 years :)

Yil
03-13-2013, 08:50 PM
Hehe, i386 is probably zero but i386 is I believe the default build target of the compiler since that code will run anywhere. ioFTPD itself would probably get little benefit from requiring a "better" instruction set, but OpenSSL for SSL transfers might get a big benefit. That's why ioFTPD uses unmodified OpenSSL libraries so people can substitute better ones, but unless you have an old computer on a really fast line it probably doesn't make a lot of difference anyway.

I do have an old Athlon XP running ioFTPD just fine somewhere :)

hennie1nl
03-18-2013, 08:37 PM
I upgraded a pc from vista to windows 8...now ioftpd all of a sudden does not see networks shares from the windows 8 pc anymore...explorer sees the shares fine but ioftpd won't. Looks like some permissions problem introduced by windows 8. What exactly do i need to configure for ioftpd to recognize windows 8 shares? Stupid question..i know but please help me out.

Yil
03-18-2013, 11:56 PM
I haven't used windows 8 so not really sure what to tell you... However when you say "network shares" are you actually using them in the .vfs as //computer/share or are you mounting them to a drive letter and then using that? Are you running ioftpd as a user or as a system service? If a service are you running it as a user and not the under default system account? [Using the Local System account to access remote shares is probably a bad idea!]

I'm not sure if vista or win7 introduced homegroups, but that might factor into things as well. Is the machine you are mounting shares from running XP or something newer?

Just to rule out a bunch of problems try running it directly as a user who can see the shares and see if that makes a difference...

hennie1nl
03-20-2013, 09:31 PM
Thanks for the quick reply Yil...truly amazing support! :-)
Yes when i say networkshares i'm using them in the vfs as //computer/share.
I'm running ioftpd as system service with logon as a user (who can see the shares).
Vista introduced home groups i think.
The machine which runs ioftpd is running Windows 7 Ultimate 64 bit.
I'm really baffled here why ioftpd won't see the shares :-(

Yil
03-21-2013, 12:12 AM
Since ioFTPD didn't change during your OS upgrade I'm going on the assumption that it's window's fault :)

In theory you can check the credentials used to automatically login to your share via: Control Panel\All Control Panel Items\Credential Manager. However, googling has suggested that there is an issue with mounting shares when done as a user who is an administrator. What's really interesting is that it looks like the behavior depends upon your setting for UAC (user account control). My guess is you might have disabled this under vista because it had so many annoying popups about everything, but win7/8 fixed most of that so you probably left it on. Search for "EnableLinkedConnections" and see if setting that registry entry fixes anything...

Yil
03-21-2013, 12:50 AM
Two other things I just thought of! The ioFTPD logs directory should contain a list of error messages about failed mountpoints. It should generate that either during preloading or during the first login using that vfs file. Find the message and lets look at the error code so we can find out what's going on...

Perhaps you need to enter the names of the machines into the lmhosts and/or hosts file? It's possible that during startup the server hasn't joined the domain yet and can't resolve share names unless manually entered? You could probably test this by re-starting the service after you login and see if that makes a difference.

o_dog
03-21-2013, 01:07 PM
YiL: TCL in 64bit is no real problem, runs just fine. Old libraries built for 32bit do not work with it though making most scripts useless.