sendemail only runs from cmd launched from scheduler?!

[taripo]

perl is normally an interpreted language, but it can be compiled, i'll look into how to do that, and give that a try.

[aGerman]

perl is normally an interpreted language

Yes I know. Probably that's the reason why the .exe file is an sef-extracting file (7-Zip can open it) that creates a few .dll files in your %temp% folder. I'm not familiar with Pearl so I don't know what they are good for.

Regards
aGerman

[penpen]

Does Task Manager show that process explorer is running like this? or any command show it?

No, as you could create too complex rights: For example you could forbid a single User to execute cmd.exe.
The only rights group that is easy to describe is "system rights": All is allowed.

I don't see that SSLEAY32.DLL file listed in process explorer.
(...)
(Maybe sendemail quickly finishes using SSLEAY32.DLL and so it doesn't show up in process explorer).

Yes, that could be the reason. You could use the process monitor instead.
You should modify the filters to reduce the amount of data displayed, to easily see what you need.
It should log all events, if not filtered, when executing with system rights.
It also gives you the path of the dll's used.

I don't know why sysinternals sigcheck shows it with an i

The version number could be divided in parts: "<version>.<subversion>.<build>.<revision>".
So "1.0.1.9" is version 1, subversion 0, build 1, revision 9.
It is more or less common to use letters instead of the revsion, and because the version was not revised on revision number 0 no letter is appended in that case:
- "3.2.1.0" == "3.2.1"
- "3.2.1.1" == "3.2.1a"
- "3.2.1.2" == "3.2.1b"
- "3.2.1.3" == "3.2.1c"
- ...

Is it possible to have determined that without having XP 32bit? So if i'd just had Win7 64bit with its not working DLLs 'cos wrong version.

Yes, it is possible; see my first post:

This happens, if an executable is linked against a dll with a different version, than actually used by your account/system.

Dependency Walker, Process Explorer, and Process Monitor only should help you to find all involved dlls (name and path).
You could for example search for the SSLEAY32.DLL and temporary move one of them to another directory.
Then try to start the application and see, if the error message changes.
Based on the new error message you could do "this or that".
The really BIG problem is to find the right version of the involved dll's.
So you are lucky to find the working ones so fast.
But the good news is, that only happens on an odd dll design and never should happen on good dll design.

A function is defined and exported by a dll using a unique name and ordinal (id).
The name and id should never change in any later version of that dll.
Functions should not be removed in later versions, but replaced by bugfixed ones.
Deprecated functions should be replaced by a function, that displays an "Function is Deprecated since version <version>.<subversion>.<build>.<revision> !" Message.

And is it possible to determine what the dll process is that he used that'd be responsible.. that is requiring early versions of those two DLLs?

It should be possible using Process Monitor.

Also strange that sendemail on the XP 32bit machine, seems to use the DLLs in the directory it is run from.
Whereas on the Win7 64bit machine, it doesn't, it only uses the ones in c:\windows\syswow64

Very odd indeed, but i think it has to do with the behaviour described in the msdn link, that aGerman has provided.

penpen

[taripo]

Since aGerman has pointed out that that EXE isn't a normal EXE.. but some kind of self extracting file. (Note, opening it in 7zip one sees some files/folders there though not the dlls themselves).

I have come to the realization that running perl as it was designed to be (from the pl file directly), is more reliable.. This self extracting perl exe thing (probably created via PP Packer or Perl2exe), looks like a bit of a hack.. not really using the same DLLs that the pl file uses. Running the pl file on win7 I see it uses this dll file from the perl installation C:\Perl64\lib\auto\Net\SSLeay\SSLeay.dll (so, different to the c:\windows\syswow\ssleay32.dll that the exe used and crashed with when it was the wrong version) The XP comp doesn't have perl installed but if it did i'm sure the pl file would use the same dll as the pl uses on the 7 comp(i.e. from perl directory) and would thus work fine/properly.

Apparently there is another way of compiling it which is real compiling - to native, done by a program called perlcc which maybe was included with perl at some period, but people found it buggy and it went out of use for years in favour of pp packer and perl2exe, but perlcc has had some recent work done on it as of 2014. And that really compiles it, e.g. it runs faster as an EXE apparently - if compiled like that. But I won't be taking that route.

I'm going to just stick to running it from the pl file. That's how perl's meant to be run

And the EXE file I have.. is not a machine code one, but is something with an interpreter bundled in it and isn't worth using when I have / can put perl on my machines and run the perl file directly, in the same manner that a python(.py) program is run. Associated with the interpreter.. run as C:\blah>nameofplfile.pl <ENTER> is how it's meant to be run. And adding .pl to the PATHEXT variable, I can skip the extension .C:\blah>namepfplfile<ENTER> I was doing that before but I thought I should be able to get the EXE file running. Now I see the EXE file is a bit of a hack and not a normal EXE.. i'll run the pl file directly, that works well.

Thanks