Re: [boinc_dev] automatic filename extension in windows wrapper

2016-02-29 Thread Christian Beer
On 25.02.2016 21:31, Rom Walton wrote:
> I suppose it would be more robust to have the wrapper launch "cmd.exe" with 
> the command line argument of "/k" and then the desired application name.  
> That would then allow cmd.exe to launch the desired application correctly.

How would that impact suspending and resuming the legacy app? How would
we specify "does not have an ending"? No "." within the last 4 characters?

We'll have a Windows build environment shortly, test this locally and
create a pull request if successful.

Regards
Christian
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] automatic filename extension in windows wrapper

2016-02-27 Thread Bernd Machenschalk

Bernd Machenschalk wrote on 26.02.16 07:00:
Speaking about wrapper: would it hurt anyone if the "macros" 
(NTHREADS, GPU_DEVICE and in particular PROJECT_DIR) would be replaced 
in the complete command-line passed to the worker _after_ the 
arguments to the wrapper have been added ()? 
This way one could pass "resolved" file names to the "worker 
application". One possibly needs to circumvent the shell 
interpretation of '$', e.g. by using '%' ('"%PROJECT_DIR") on the 
command-line.


Thinking more about that I think it would even be better to have a 
possibility to boinc-resolve files in the command-line (or in an 
environment variable setting), in cases where the resolved name is not 
known when the command-line is built. Say a phrase like 
"boinc_resolve()" on the command-line is replaced by the 
"boinc_resolve"d .


Currently you can only tell the wrapper to copy a input or output file, 
which is a bad choice for large files, or to pack/unpack it in a zip 
file, which unnecessarily complicates e.g. validation assimilation etc.


Best,
Bernd

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] automatic filename extension in windows wrapper

2016-02-26 Thread McLeod, John
For Windows, % is not a good choice.  Windows will try to interpret them as 
either System Variables %VarName% or batch file parameters %1.

-Original Message-
From: boinc_dev [mailto:boinc_dev-boun...@ssl.berkeley.edu] On Behalf Of Bernd 
Machenschalk
Sent: Friday, February 26, 2016 1:00 AM
To: Christian Beer <christian.b...@aei.mpg.de>; BOINC Developers Mailing List 
<boinc_dev@ssl.berkeley.edu>
Subject: Re: [boinc_dev] automatic filename extension in windows wrapper

Speaking about wrapper: would it hurt anyone if the "macros" (NTHREADS, 
GPU_DEVICE and in particular PROJECT_DIR) would be replaced in the 
complete command-line passed to the worker _after_ the arguments to the 
wrapper have been added ()? This way one could 
pass "resolved" file names to the "worker application". One possibly 
needs to circumvent the shell interpretation of '$', e.g. by using '%' 
('"%PROJECT_DIR") on the command-line.

Bernd

Christian Beer wrote on 25.02.16 21:09:
> Hi,
>
> we have a use case where we want to use the wrapper to deploy a legacy
> application. The application is bundled in a zip archive that is
> extracted by the wrapper into the slot directory. This application is
> called "LegacyApp" and "LegacyApp.exe" on Linux and Windows
> respectively. Now comes the problem. We want t include the job.xml file
> as part of the workunit not the appversion. This way we can only set one
> name "LegacyApp" which causes problems because for an unknown reason
> Windows 7 will not start a file without the .exe extension.
>
> I looked through the code and found a place
> (https://github.com/BOINC/boinc/blob/master/samples/wrapper/wrapper.cpp#L633)
> where we could add some more logic to detect such a case and add the
> ".exe" extension. Something like: if on windows and app_path does not
> exist try app_path+".exe"
>
> Another possibility would be to also add the .exe extension to the linux
> executable but who want's to do that? And remember it later when we
> wonder why we fixed a Windows Problem on Linux.
>
> Any thoughts on that?
>
> Regards
> Christian

___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] automatic filename extension in windows wrapper

2016-02-25 Thread Bernd Machenschalk
Speaking about wrapper: would it hurt anyone if the "macros" (NTHREADS, 
GPU_DEVICE and in particular PROJECT_DIR) would be replaced in the 
complete command-line passed to the worker _after_ the arguments to the 
wrapper have been added ()? This way one could 
pass "resolved" file names to the "worker application". One possibly 
needs to circumvent the shell interpretation of '$', e.g. by using '%' 
('"%PROJECT_DIR") on the command-line.


Bernd

Christian Beer wrote on 25.02.16 21:09:

Hi,

we have a use case where we want to use the wrapper to deploy a legacy
application. The application is bundled in a zip archive that is
extracted by the wrapper into the slot directory. This application is
called "LegacyApp" and "LegacyApp.exe" on Linux and Windows
respectively. Now comes the problem. We want t include the job.xml file
as part of the workunit not the appversion. This way we can only set one
name "LegacyApp" which causes problems because for an unknown reason
Windows 7 will not start a file without the .exe extension.

I looked through the code and found a place
(https://github.com/BOINC/boinc/blob/master/samples/wrapper/wrapper.cpp#L633)
where we could add some more logic to detect such a case and add the
".exe" extension. Something like: if on windows and app_path does not
exist try app_path+".exe"

Another possibility would be to also add the .exe extension to the linux
executable but who want's to do that? And remember it later when we
wonder why we fixed a Windows Problem on Linux.

Any thoughts on that?

Regards
Christian


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] automatic filename extension in windows wrapper

2016-02-25 Thread yoyo
I had the same issue in the past with cmsearch in RNA World. Job.xml is
part of the workunit and the Windows binary doesn't have the .exe
extension.
But I don't remember if it was running especially on Windows 7.



Christian Beer schrieb:
> Hi,
> 
> we have a use case where we want to use the wrapper to deploy a legacy
> application. The application is bundled in a zip archive that is
> extracted by the wrapper into the slot directory. This application is
> called "LegacyApp" and "LegacyApp.exe" on Linux and Windows
> respectively. Now comes the problem. We want t include the job.xml file
> as part of the workunit not the appversion. This way we can only set one
> name "LegacyApp" which causes problems because for an unknown reason
> Windows 7 will not start a file without the .exe extension.
> 
> I looked through the code and found a place
> (https://github.com/BOINC/boinc/blob/master/samples/wrapper/wrapper.cpp#L633)
> where we could add some more logic to detect such a case and add the
> ".exe" extension. Something like: if on windows and app_path does not
> exist try app_path+".exe"
> 
> Another possibility would be to also add the .exe extension to the linux
> executable but who want's to do that? And remember it later when we
> wonder why we fixed a Windows Problem on Linux.
> 
> Any thoughts on that?
> 
> Regards
> Christian
> ___
> boinc_dev mailing list
> boinc_dev@ssl.berkeley.edu
> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
> 

-- 
Rate Me ,  MySkype
(yoyo_rkn)Skype Me™!  , myICQ 139003243 , myIRC


Rechenkraft.net e.V.  - Verein zur Förderung
von Bildung, Forschung und Wissenschaft durch Einsatz vernetzter Computer
weitere interessante Projekte
und
Hilfe auf unserer
Webseite www.Rechenkraft.net  und im Chat


Rechenkraft.net e.V.   - Non-profit
association for the promotion of education, research and science through
the use of networked computers
other interesting projects
and
help  on our
website www.Rechenkraft.net  and on IRC


___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


Re: [boinc_dev] automatic filename extension in windows wrapper

2016-02-25 Thread Rom Walton
I suppose it would be more robust to have the wrapper launch "cmd.exe" with the 
command line argument of "/k" and then the desired application name.  That 
would then allow cmd.exe to launch the desired application correctly.

.COM/.EXE apps can be launched directly with CreateProcess/CreateProcessEx
.VBS/.JS/.WSH would be launched with wscript.exe
.BAT/.CMD would be handled by the currently running command interpreter

In theory this could also take care of python/perl files as well.  As long as 
the interpreters are installed on the system.

- Rom

-Original Message-
From: Christian Beer [mailto:christian.b...@aei.mpg.de] 
Sent: Thursday, February 25, 2016 3:09 PM
To: BOINC Developers Mailing List 
Cc: Rom Walton 
Subject: automatic filename extension in windows wrapper

Hi,

we have a use case where we want to use the wrapper to deploy a legacy 
application. The application is bundled in a zip archive that is extracted by 
the wrapper into the slot directory. This application is called "LegacyApp" and 
"LegacyApp.exe" on Linux and Windows respectively. Now comes the problem. We 
want t include the job.xml file as part of the workunit not the appversion. 
This way we can only set one name "LegacyApp" which causes problems because for 
an unknown reason Windows 7 will not start a file without the .exe extension.

I looked through the code and found a place
(https://github.com/BOINC/boinc/blob/master/samples/wrapper/wrapper.cpp#L633)
where we could add some more logic to detect such a case and add the ".exe" 
extension. Something like: if on windows and app_path does not exist try 
app_path+".exe"

Another possibility would be to also add the .exe extension to the linux 
executable but who want's to do that? And remember it later when we wonder why 
we fixed a Windows Problem on Linux.

Any thoughts on that?

Regards
Christian
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.


[boinc_dev] automatic filename extension in windows wrapper

2016-02-25 Thread Christian Beer
Hi,

we have a use case where we want to use the wrapper to deploy a legacy
application. The application is bundled in a zip archive that is
extracted by the wrapper into the slot directory. This application is
called "LegacyApp" and "LegacyApp.exe" on Linux and Windows
respectively. Now comes the problem. We want t include the job.xml file
as part of the workunit not the appversion. This way we can only set one
name "LegacyApp" which causes problems because for an unknown reason
Windows 7 will not start a file without the .exe extension.

I looked through the code and found a place
(https://github.com/BOINC/boinc/blob/master/samples/wrapper/wrapper.cpp#L633)
where we could add some more logic to detect such a case and add the
".exe" extension. Something like: if on windows and app_path does not
exist try app_path+".exe"

Another possibility would be to also add the .exe extension to the linux
executable but who want's to do that? And remember it later when we
wonder why we fixed a Windows Problem on Linux.

Any thoughts on that?

Regards
Christian
___
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.