Local Personal SMTP Server

[stanlyn]

Hi,

I'm looking for a small and local (on same machine) SMTP service or app that always runs outside of VFP on the same machine so that when I send an outgoing email from my VFP app, this service or app intercepts and contacts the actual smtp server for delivery. My app remains completely responsive at all times even when there are network, smtp or other external issues. I'm using it to send error emails with screenshots back to us.

Currently I send it to the smtp server directly from VFP and because now I'm including screenshots in the emails, the app is tied up for way too long, like 30-40 seconds for a 3.5mb screenshot file. I want the app to only prepare the email and hand it off to this ??? (that is outside my app) and continue doing what the app does with zero user delays...

I briefly look at the "VFP Parallel" processing articles a while back and wondering if that is overkill for this task?

I also looked at SmtpQ product from ChilKat which does exactly what I want, except it is only available in 64b...

Something simple is preferred?

Any ideas?
Stanley

 

[stanlyn]

Olaf,

It is NOT failing to find the MailSender.exe immediately. I'll say it again, for testing purposes I added a messagebox at the entry point in MailSender.exe. Both run /N and shellexe displays the messagebox immediately. The only difference is run /n tiesup the Main program and shellexe does not. If what you say is correct, then the messagebox would be delayed until mailSender can be found.

That is not happening here at all no matter what the adir command says. When I said in my last post "I did not know what your adir command does", what I should have said, was "I'm at the end of a 20 hour day and 7 hour past my bedtime and I'm not running on all cylinders......." (sorry)

I originally had the path hardcoded, but will test again in an attempt to answer the why.

I will also add curdir() results to the test messagebox in the MailSender program as well as a timer. I'll pass the starting seconds() to a table field in the main program and let the sender supply the ending seconds() and display the results in the messagebox as well.

Will report this back.

Thanks,
Stanley

 

[stanlyn]

OK, results are in...

With the path to MailSender.exe as 'd:\cpos\server\mailSender.exe' (hardcoded). Here is a small screenshot showing the curdir()s and time stamps.

See next post for image...


Now here it is again with the hardcoding removed... (relative pathing)

As you can see, it is finding it in milliseconds in both uses. The messagebox is generated in the MailSender.exe.

Any other testing ideas?

Thanks, Stanley

 

[stanlyn]

The hardcoded screenshot is here,,,

Thanks, Stanley

 

[Olaf Doschke]

> I'll say it again, for testing purposes I added a messagebox at the entry point in MailSender.exe. Both run /N and shellexe displays the messagebox immediately
I don't see where you said so before or showed this in source code, anyway I have no idea where that tie up comes from´and does not happen with ShellExecute.

I did monitor events with processmonitor.exe and there is not much of a difference in using both.

Now, besides the remaining mystery, is your problem solved by using ShellExecute?

Bye, Olaf.

 

[strongm]

>I don't see where you said so before

First line of post timestamped 23 Jan 16 12:57

Fixed it with shellexec from Mike's site

>RUN does start the EXE and doesn't wait for it at all

RUN can be a pain because of the way it interacts with the command shell, and so sometimes doesn't quite do what you expect it to.

 

[Olaf Doschke]

strongm, I refer to stanlyn saying he put a messagebox at the start of his mailsender.exe before his posted "I'll say it again" in his post 24 Jan 16 07:04, not the first time he posted about using ShellExec.
Besides you're only half right with RUN interacting with the command shell, that does not apply to RUN /N, it only applies to RUN without the /N option. I also pointed out that difference already, not only the NOWAIT vs WAIT difference it makes, in my example running notepad.exe both ways. You can also verify with Process Monitor, that RUN /N doesn't make use of the shell or whatever %COMSPEC% specifies or a pif file.

I still don't see why RUN /N fails so miserable in Stanlyns case.

Bye, Olaf.

 

[strongm]

Sorry, cut'n'pasted wrong comment. Instead of "I don't see where you said so before" I actually meant " is your problem solved by using ShellExecute?", otherwise my comment doesn't actually make any sense whatsoever.

> RUN /N doesn't make use of the shell or whatever %COMSPEC% specifies or a pif file

It does, however, make use of Shell32

 

[stanlyn]

Hi,

>> I don't see where you said so before or showed this in source code,
Refer to three messages with time stamps of:
23 Jan 16 12:57,
again at 24 Jan 16 07:04
and yet again at 24 Jan 16 08:12

>> Now, besides the remaining mystery, is your problem solved by using ShellExecute?
Yes, so I guess we walk away with another VFP mystery? I hate not knowing why...

Did you see anything abnormal in the process viewer?

Also Olaf, when putting the test together that showed the curdir() and elapsed times of using absolute vs relative pathing, I noted this:

run /n 'd:\cpos\server\mailsender.exe' fails.
run /n 'mailsender.exe' also failed.

I had to use macro expansion like this to get it to work in both relative and absolute modes.
aa='mailsender.exe'
run /n &aa

​

works, and

aa='d:\cpos\server\mailsender.exe'
run /n &aa

​

also works

Anyway, thank you very much for participating in this extra long thread, even if we walk away in mystery!

Thanks again,
Stanley

 

[strongm]

One quick question: what happens if you launch the mailsender from

Start>Run>d:\cpos\server\mailsender.exe

which is in theory around about what the FoxPro RUN /N command does eventually

 

[Olaf Doschke]

>> RUN /N doesn't make use of the shell or whatever %COMSPEC% specifies or a pif file

>It does, however, make use of Shell32
So does ShellExecute.

ShellExecute

https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx

Requirements: Shell32.dll

But this is the Windows shell, not a DOS shell as command.com or cdm.exe and these dependencies are not existing with RUN /N.

There is no reason to avoid RUN /N and if Stanlyn wants to find out why it ties up, he has to take sysinternals process monitor and let it monitor his exe or a new exe just having the RUN /N command, if that can reproduce the same tie up. If it's not reproducable it has some dependency on anything we don't have seen yet from his application or on hiw Windowse, maybe its a virus scanner suspending his exe, whatever.

Bye, Olaf.

 

[strongm]

I'm aware of that. I'm not suggesting that RUN / N is inherently a bad thing - it certainly has its place and its uses. However, it has caused problems for many FoxPro users (a trivial but annoying example being the macro expansion requirement that stanlyn mentions above) since it was originally introduced. There are plenty of problems posted about it on the internet, and it is one of the reasons that many users move to ShellExecute (or ShellExecuteEx) and CreateProcess instead - it is far more reliable, and you have more direct control. And in this case we clearly see that ShellExecute provides a working solution whilst RUN /N does not.

 

[Olaf Doschke]

While most of what you say is true, the problem with RUN /N here is a mystery, it's not about macro substitution, it's not about using cmd.exe or Shell32, it's simply a mystery only stanlyn can solve at his concrete installation of his two Executables via process monitor.

ShellExecute offers a parameter, in which you can forward commandline parameters, it offers more than the open action and thus it's a more versatile thing to use, but should not be necessary in this case.

Bye, Olaf.

 

[strongm]

>it's not about macro substitution, it's not about

I appreciate that. I was simply using those to make the point that RUN can be ... erm ... quirky. Since we don't as yet know why it is exhibiting the behavior that it is in this particular instance, it would be difficult for me to provide an exact matching example (although there are various examples out there of people for whom /N doesn't do what it is supposed to do)

I'm pretty sure that the issue here is caused by the way RUN /N starts up a single-threaded application with no GUI that goes straight into a tight loop.

 

[Olaf Doschke]

>I'm pretty sure that the issue here is caused by the way RUN /N starts up a single-threaded application with no GUI that goes straight into a tight loop.
You give a good idea what could reproduce the problem.

I don't know the RUN internals, but that makes the assumption RUN waits for some response of the new process to be successfully started, even when using the /N flag. That would be quite against the point of the flag and I don't see there would be such a generic response of any executable (since run /n is for starting windows applications in general, not only VFP ones). It would also only make sense, if RUN had a return value indicating the success of it starting something, but it does not. It's really a shoot and forget startup, whatever happens afterwards is only the concern of the new process and the OS.

If you're right about that cause, then I wonder what the inventors though of, when implementing this. I still think something else here plays a role, like antivirus getting suspicious about his main process starting another process (though that is a very common thing of processes to do). Something third party might be involved here, that differs on his system, nothing that we might reproduce, unless we have the same involved component, just by chance.

Bye, Olaf.

 

[strongm]

> but that makes the assumption RUN waits for some response

That is correct. In this case it is clearly doing exactly that, even if you don't want it to be doing so. You think the /N tells the RUN command not to wait, whilst I'm pretty sure it tries to tell the API call(s) it subsequently uses not to wait, a subtle but important difference - and it is here that the problem lies (and whether RUN itself returns a value is neither here nor there)

>then I wonder what the inventors though of, when implementing this

RUN was a bit of a hack when it was introduced, and designed to work with CMD.COM. 'Moderen' behaviour is an artifact of its history ...

 

[Olaf Doschke]

>You think the /N tells the RUN command not to wait, whilst I'm pretty sure it tries to tell the API call(s) it subsequently uses not to wait
That's total nonsense, as you can test yourself with RUN /N notepad.exe and a next line in VFP code also is executed before you close notepad.

No, I'm very sure /N is for NOWAIT in general, and it works in general.

Bye, Olaf.

 

[strongm]

One test worth doing would be for Stanlyn to make the mailsender.exe display a top-level form at startup (it doesn't have to do very much), and perhaps also set AutoYield to true. And then retry the tests

 

[Olaf Doschke]

>RUN was a bit of a hack when it was introduced
I was not talking about RUN but about the /N switch behaviour only.

Bye, Olaf.

 

[Olaf Doschke]

>make the mailsender.exe display a top-level form at startup

I don't know why you think that would be important. Even without having any form and even with SCREEN=OFF there are two VFP objects always present, also at runtime in an EXE: _SCREEN and _VFP, and both have a hwnd. If you think only a hwnd windows handle makes a process complete, it's already there.

Besides that you have _VFP.ProcessID and _VFP.ThreadID to identify these process and thread properties.

You can access all this even in the first line of your VFP code of your main prg, the runtime has already created these things in it's exe stub code part of any VFP exe.

If your earlier assumption is correct I would suspect RUN would need the new process to go into it's idle state (READ EVENTS in VFP) to allow RUN /N to end and do the next step in its own process, and that obviously is not the case with mailsender.exe. Therefore a viable idea.

One way to do the opposite, to wait for another process, is by using the WaitForSingleObject API function and process monitor doesn't show that API call. In general processes don't depend on each other, their total independence without any active interfacing (like the waiting for each other or using shared memory or pipes) is their main property from the OS perspective alone, therefore I don't think it's hard to program RUN with the /N option to create a new process and exit from it's own execution without getting tied by the new process. It would be a dumb implementation of the /N switch to wait for some state of the new process.

We'll see.

I made two executables. One with merely READ EVENTS, one with DO WHILE .T. / ENDDO. In both cases RUN /N does come back quite fast and the calling process continues, eg showing a messagebox. No tie up. Also with SCREEN=OFF config.fpw included. The same after setting AutoYield =.F.

So these assumptions are already tested.

Bye, Olaf.

 

[strongm]

>I don't know why you think that would be important

Depending on how Foxpro handles it, it could be very important to WaitForInputIdle, nothing to do with WaitForSingleObject, which as I am sure you are aware is related to Windows events, which is a slightly different thing and unlikely to be the method RUN USES