Doesn't seem to work, here's what I get.
In case this is relevant, when I had installed FAH and the windows firewall permission prompt came up, I allowed private network but blocked public network communication. I figured I could always change it later if necessary. This is a desktop in a home environment anyway.
Welcome to Microsoft Telnet Client
Escape Character is 'CTRL+]'
Microsoft Telnet> telnet 137.0.0.1 36330
Invalid Command. type ?/help for help
Microsoft Telnet> 137.0.0.1 36330
Invalid Command. type ?/help for help
Microsoft Telnet> open 137.0.0.1 36330
Connecting To 137.0.0.1...Could not open connection to the host, on port 36330: Connect failed
Microsoft Telnet>
Web Control still does not work in a normal Chrome window but it does work in an Incognito window. It also works in an Internet Explorer 8 InPrivate window. Any ideas? I don't know if Eset NOD32 is interfering with the Web Control but if that were it why would both browsers work in Incognito and InPrivate modes?
Ghetto_Child wrote:Web Control still does not work in a normal Chrome window but it does work in an Incognito window. It also works in an Internet Explorer 8 InPrivate window. Any ideas? I don't know if Eset NOD32 is interfering with the Web Control but if that were it why would both browsers work in Incognito and InPrivate modes?
Are you behind a corporate firewall? Private windows probably go through an anonymizing gateway, thereby avoiding your companies firewall restrictions.
To address the iostream error issue,
I have a similar issue using the 'portable version' of FAH.
Since NACL has finished, the binaries found on the site, allow me to run FAH, without installing it, and without admin privileges.
In a way, the same as NaCL, but no browser option.
I have the same issue running fahClient (CPU only) on Windows 10.
And I know it's because the program hasn't started the way it was supposed to start.
But for those who run FAHClient binaries, via a CMD window (with no install),
So far, I get the issue when exiting abruptly (closing CMD window, or repeatedly pressing CTRL + C).
Fah shuts down, but leaves one of the work directories (or files) as read-only (...."fah\work\00" folder)
The issue is resolved by closing FAH, and removing the 'read-only' tag from the '00' folder (right click, properties, remove 'read only' checkbox), and restarting fah.
I'm also running fahClient (CPU) on Windows 7, but haven't seen any access denied errors there.
Also, setting the 'hidden' option in Task Scheduler, to schedule FAH to start at boot (for those without admin rights), the 'hidden' option doesn't work. There's a FAH icon appearing in Windows Systray, but it's non functional, disappears, or causes errors with the cmd line.
Again, due to not running FAH the way it was intended (with installation), but FAH binaries do work without installation of any kind.
So, to summarize, I think the iostream errors can be prevented, by removing the read only lock on the directories.
bruce wrote: ↑Thu Feb 07, 2019 4:21 amThe target of the shortcut created by FAH says "...hide-console ... FAHClient ...." which redirects the console output of the program that it starts so there's no output to a window.
Can you list here the values of all shortcut fields that correspond to the correct shortcut created by the application installer?
Объект
Рабочая папка
Быстрый вызов
Окно
Комментарий
Дополнительные свойства / Запуск от имени администратора ("Позволяет запустить программу от имени администратора> в то же время защищая компьютер от несанкционированных действий.")
Запускать в отдельной области памяти
Совместимость
что-то еще?
(I am using Microsoft Windows 10.0.19045.3086 with russian GUI, FAHClient 7.6.21)