67 replies to this topic

[sbaeder]

I'm getting rather tired of hearing all the fighting back and forth about winbuilder.exe vs. api script. enough already. they both need work. sure, API is not as optimized as it could be but winbulder.exe has gotten slower as well. your BOTH the problem. so lets fix BOTH!

A M E N !!! What we need is more and a LOT less

[sbaeder]

Very well said.

Yet again, Wonko *truly* is the "SANE" one here

[Galapo]

: You have finally understood that one can accomplish many functions faster if he / she looses the "Performs everything" condition.
That took more than one year!

Peter, we knew this all along! It hasn't taken more than a year. But Lancelot and I have been using 077rc2 during that time which processes quicker, so haven't needed to look at optimising CAPI much. we've been more focussed on writing scripts than developing CAPI. CAPI has been the domain for Pedro. But since our project started supporting 080, it has become more of an issue. Hence we're trying to revise CAPI a bit.

There is no back compatibility! ALL apps scripts which want to become faster, because they do not need the oldfashioned functionality, MUST be rewritten.

Nope, that's wrong. Current app scripts will now process faster due to optimisation with require_file. If that's not the case, please provide logs. In my testing with LiveXP it's around 10% faster as reported previously above. Hence there is backwards compatibility since the same syntax and same commands as before are supported. If you read CAPI you'll see this. That's backwards compatibility as I know it. No app scripts on the LiveXP server have had to be updated with the revisions made to require_file and yet build time is significantly improved.

@Galapo: Why you and L ...® (I'm not more allowed to write the name) do such a development step, which inside WB you VERY STRONG REFUSE?
If it is in order to get enhancements, why not allow the same for WB?
I understand that WB here is an exclusive issue, while RequireFile only is an optional issue, but progress sometimes needs some work, and the differnce is only historical, not your development result.

Peter, sorry I do not understand what you mean here. And I cannot understand who's not allowing you to write Lancelot's name.

Our revisions to CAPI do not mean that scripts need to be rewritten. Current scripts work, nothing needs to be rewritten. If that's not the case, please provide a non-working app script that was working before our revisions. All we've done is provide some optimisation and implemented an optional new function for people to use.

I've never been against this with WB. I've never been against new functions in WB --I've even proposed many myself! What I am against is fundamental syntax changes requiring scripts to be rewritten without any discussion or agreement amongst developers.

Regards,
Galapo.

[Galapo]

Hi Nuno,

How did your testing go?

Thanks,
Galapo.

[Brito]

I didn't made any progress. Still too busy with two projects that need to be delivered within 5 weeks.

[Galapo]

Ok, I was just wondering about the status of the testing. If you get a chance, report back here once done, or put a link here to the topic.

Regards,
Galapo.

[homes32]

could winbuilder be made to read the stdout and stderr streams of a program launched with ShellExecute and log the contents to the log? this could be a solution to the logging problem with using external programs.
also it could provide a way to "return" information back to winbuilder without using an .ini file to pass information.
example:

ShellExecute: [Hide] using: [%BaseDir%\Projects\Tools\Win7PE_SE\7z.exe] with parameters: [x -y "%BaseDir%\Workbench\Common\blablabal.zip" -o"%BaseDir%\Workbench\Common\ExtractHere"]
--- 7z.exe output start ---
bla bla
bla bla
bla bla
{WinbuilderDO:Set,%somevar%,"someValue"}
-- 7z.exe output end ---

where whenever {WinbuilderDO: is encountered everything following the : and ending with } is treated as a winbuilder command to be executed
just some ideas.

[pscEx]

could winbuilder be made to read the stdout and stderr streams of a program launched with ShellExecute and log the contents to the log? this could be a solution to the logging problem with using external programs.
also it could provide a way to "return" information back to winbuilder without using an .ini file to pass information.
example:

ShellExecute: [Hide] using: [%BaseDir%\Projects\Tools\Win7PE_SE\7z.exe] with parameters: [x -y "%BaseDir%\Workbench\Common\blablabal.zip" -o"%BaseDir%\Workbench\Common\ExtractHere"]
--- 7z.exe output start ---
bla bla
bla bla
bla bla
{WinbuilderDO:Set,%somevar%,"someValue"}
-- 7z.exe output end ---

where whenever {WinbuilderDO: is encountered everything following the : and ending with } is treated as a winbuilder command to be executed
just some ideas.

Yes it could.
There is a 7 years old solution: http://www.codeproje...cess_patch.aspx

Peter

[paraglider]

What has a mechanism used by a .NET application to launch a process and capture its output got to do with with winbuilder. Here is how you do it it c++:

    HANDLE hOutputReadTmp,hOutputWrite;

    HANDLE hInputWriteTmp,hInputRead,hInputWrite;

    HANDLE hErrorWrite;

    char sd[SECURITY_DESCRIPTOR_MIN_LENGTH];

    PSECURITY_DESCRIPTOR pSD=(PSECURITY_DESCRIPTOR)sd; 

    SECURITY_ATTRIBUTES sa={sizeof(sa),sd,TRUE};



    InitializeSecurityDescriptor(pSD,SECURITY_DESCRIPTOR_REVISION);

    SetSecurityDescriptorDacl(pSD,TRUE,(PACL) NULL,FALSE);







    // Create the child output pipe.

    if (!CreatePipe(&hOutputReadTmp,&hOutputWrite,&sa,0))

    {

        DWORD err = GetLastError();

        AtlTrace(_T("Failed to create pipe,%p(%u)\n"),err,err);

        return 1;

    }



    // Create a duplicate of the output write handle for the std error

    // write handle. This is necessary in case the child application

    // closes one of its std output handles.

    if (!DuplicateHandle(GetCurrentProcess(),hOutputWrite,

        GetCurrentProcess(),&hErrorWrite,0,

        TRUE,DUPLICATE_SAME_ACCESS))

    {

        DWORD err = GetLastError();

        AtlTrace(_T("Failed to duplicate handle,%p(%u)\n"),err,err);

        return 2;

    }





    // Create the child input pipe.

    if (!CreatePipe(&hInputRead,&hInputWriteTmp,&sa,0))

    {

        DWORD err = GetLastError();

        AtlTrace(_T("Failed to create pipe,%p(%u)\n"),err,err);

        return 3;

    }





    // Create new output read handle and the input write handles. Set

    // the Properties to FALSE. Otherwise, the child inherits the

    // properties and, as a result, non-closeable handles to the pipes

    // are created.

    if (!DuplicateHandle(GetCurrentProcess(),hOutputReadTmp,

        GetCurrentProcess(),

        &m_hOutputRead, // Address of new handle.

        0,FALSE, // Make it uninheritable.

        DUPLICATE_SAME_ACCESS))

    {

        DWORD err = GetLastError();

        AtlTrace(_T("Failed to duplicate handle,%p(%u)\n"),err,err);

        return 4;

    }



    if (!DuplicateHandle(GetCurrentProcess(),hInputWriteTmp,

        GetCurrentProcess(),

        &hInputWrite, // Address of new handle.

        0,FALSE, // Make it uninheritable.

        DUPLICATE_SAME_ACCESS))

    {

        DWORD err = GetLastError();

        AtlTrace(_T("Failed to duplicate handle,%p(%u)\n"),err,err);

        return 5;

    }





    // Close inheritable copies of the handles you do not want to be

    // inherited.

    CloseHandle(hOutputReadTmp);

    CloseHandle(hInputWriteTmp);







    STARTUPINFO si;

    PROCESS_INFORMATION pi;



    memset(&si,0,sizeof(si));

    si.cb = sizeof(si);

    si.dwFlags = STARTF_USESTDHANDLES;

    si.hStdOutput = hOutputWrite;

    si.hStdInput  = hInputRead;

    si.hStdError  = hErrorWrite;



    BOOL ret = CreateProcess(

        NULL,

        m_Cmd, 

        NULL,

        NULL,

        TRUE,

        DETACHED_PROCESS,

        NULL,

        NULL,

        &si,

        &pi);

    if (0 == ret)

    {

        DWORD err = GetLastError();

        AtlTrace("Failed to start process,%p(%u)\n",err,err);

        return 6;

    }

    CloseHandle(pi.hThread);



    // Close pipe handles (do not continue to modify the parent).

    // You need to make sure that no handles to the write end of the

    // output pipe are maintained in this process or else the pipe will

    // not close when the child process exits and the ReadFile will hang.



    CloseHandle(hOutputWrite);

    CloseHandle(hInputRead );

    CloseHandle(hErrorWrite);

    CloseHandle(hInputWrite);

    __try

    {

        // This reads the output pipe until a pipe broken error is returned ( ERROR_BROKEN_PIPE )

        // ReadAndHandleOutput(m_hOutputRead);

        WaitForSingleObject(pi.hProcess,INFINITE);

        CloseHandle(m_hOutputRead);

    }

    __except ( EXCEPTION_EXECUTE_HANDLER )

    {

    }

    m_hOutputRead = INVALID_HANDLE_VALUE;

    CloseHandle(pi.hProcess);

    __try

    {

        ::SendMessage(m_OK, WM_SETTEXT,0, (LPARAM) _T("Done"));

    }

    __except ( EXCEPTION_EXECUTE_HANDLER )

    {

    }

    return 0;

[Brito]

could winbuilder be made to read the stdout and stderr streams of a program launched with ShellExecute and log the contents to the log? this could be a solution to the logging problem with using external programs.
also it could provide a way to "return" information back to winbuilder without using an .ini file to pass information.
example:

Perhaps it could be added. But beware that I am very cautious about *any* new feature. We already have enough problems to solve from the past where everything was added without taking into consideration the road ahead and just looking at the near future.

Then people fight, get angry and upset because winbuilder became too complex and I don't want to see that happening again.

where whenever {WinbuilderDO: is encountered everything following the : and ending with } is treated as a winbuilder command to be executed
just some ideas.

This is not consistent with our programming paradigm my friend.

[paraglider]

I have to agree - how many times in building a project do you need to run a program and capture its output? If its only a small number then writing to a file and reading that file is no great overhead.

[sbaeder]

What has a mechanism used by a .NET application to launch a process and capture its output got to do with with winbuilder. Here is how you do it it c++:

Great to have more examples...I think the point was to just show that it is possible, that it's not trivial to take into account all the asynch stuff that happens to make sure you get all the output in the right order (if you are trying to get both stdout and stderr), etc...

But at the end of the day, I agree that while possible, not a priority at this point in time...Heck, if you really wanted to be "crazy" (like a fox?), you could have the external program write a "script" that can then be executed where it sets global variables, or does other real work (Hmmm...like reg2WBS does )

[homes32]

Perhaps it could be added. But beware that I am very cautious about *any* new feature. We already have enough problems to solve from the past where everything was added without taking into consideration the road ahead and just looking at the near future.

true, but being able to log output would be extremely helpful, especially in the case of wim mounting/unmounting or using external programs to perform API tasks. having a logoutput statement added to ShellExecute could make it an opt-in feature so the log won't get cluttered by unwanted output while still allowing script/project developers to output important info to the log.
we discussed this in the begining of the thread. http://reboot.pro/11...post__p__103077

This is not consistent with our programming paradigm my friend.

nope! it was just a quick and dirty example illustrating a possible method to retrieve information back from a program that was run.
In any case, this isn't as important as actually being able to log the output for debugging. the ini method works fine for small amounts of data.

[sbaeder]

While maybe not a show-stopper for 81, I agree that being able to capture the output logs from external commands is a very worthy capability!

[Flyboarder]

Hey guys long time no post (from me),

So I'm just gonna throw a crazy idea out here and my thoughts about the issues, so please try to be nice when you reply.

First I must say that updating my projects when new versions of wb are released has never been much of an issue because things don't change that much between versions. Until now where 81 and 82 break my GUI and fixing them kills how the scripts look in older versions.
80 is my favorite version!!!

CAPI is bloated and in my opinion provides some redundant features, with that said I know I'm not one to talk because I'm not working with it. BUT I also understand that until recently CAPI didn't need to care about that, and as I understand the devs are working to improve it which is great.

WB has gotten slower but I was able to decrease build times by 4 minutes on my project by adding two little letters to a few commands.

My idea for WB : redesign! Well not really...... But it might help. My real idea is to make a WB that would take a dll that has all build in commands. Ex get CAPI out of .scripts rewrite it as a dll that WB can use for it's commands replacing the standard functions.

[sbaeder]

Hey guys long time no post (from me),

So I'm just gonna throw a crazy idea out here and my thoughts about the issues, so please try to be nice when you reply.

First I must say that updating my projects when new versions of wb are released has never been much of an issue because things don't change that much between versions. Until now where 81 and 82 break my GUI and fixing them kills how the scripts look in older versions.
80 is my favorite version!!!

What sort of "errors" on the look of the GUI???

We should be able to make it work right in all the cases!

CAPI is bloated and in my opinion provides some redundant features, with that said I know I'm not one to talk because I'm not working with it. BUT I also understand that until recently CAPI didn't need to care about that, and as I understand the devs are working to improve it which is great.

WB has gotten slower but I was able to decrease build times by 4 minutes on my project by adding two little letters to a few commands.

You should really try the newest 82, since has the compat,OFF by default, which makes access to variables MUCH faster!

My idea for WB : redesign! Well not really...... But it might help. My real idea is to make a WB that would take a dll that has all build in commands. Ex get CAPI out of .scripts rewrite it as a dll that WB can use for it's commands replacing the standard functions.

Not sure CAPI needs to be compiled code, but that is the beauty of opinions - we all have them There is a place for compiled in things and extensions using a DLL, and a place for interpreted things...

But having said that, major re-writes are a BIG task - however, I think something is "afoot"...

Scott

[Flyboarder]

@Scott

http://reboot.pro/11...__fromsearch__1

I never heard back when I posted my problem, see above final post. 82 from what I saw only had minor GUI issues like alignment but if I fix then then it is all off in any lower versions, seems lately all WB versions break my gui's

[paraglider]

What has that question got to with the topic of this thread?