74 replies to this topic

[Galapo]

Yes its actually VistaPE Multiboot that is actually causing the issue, copying the @180Kb 7z.exe from the main Tools folder to try and overcome this does some odd stuff....for one it doesnt change the flag when you do another update check, its still there and its looking for a @140Kb 7z.exe, and when you actually do the download, for god knows what reason the @140Kb 7z.exe that is supposed to go into the VistaPE Multiboot project ends up overwriting the @180Kb one in the main Tools folder. From there its just circular....

OK, good to know that the issue isn't with LiveXP. I tend to keep projects separate from each other so that project incompatibility is less of a problem. I do keep nativeEx and LiveXP under the same directory, though, as I try to keep LiveXP standardised to nativeEx.

Regards,
Galapo.

[pscEx]

Hehe jaclaz is used to me. Having said that, even im surprised at times that ive survived so long at 911cd.net forums without being banned

I personally welcome you here, as long as your posts are reasonable and seem to bring success to the forum's content

Peter

[thunn]

I've been running Visa lately, but now find myself on my windows 2000 putter, which still does quite well after a year of running the same os image. I crossed my fingers as I downloaded the new wb, hoping for the best.
But, w2k users are still out of luck.
I think this is not the highest priority, but should be investigated, hmm.. ?

What do you think, guys?

[pscEx]

I've been running Visa lately, but now find myself on my windows 2000 putter, which still does quite well after a year of running the same os image. I crossed my fingers as I downloaded the new wb, hoping for the best.
But, w2k users are still out of luck.
I think this is not the highest priority, but should be investigated, hmm.. ?

What do you think, guys?

I made a test on my W2000 Server:

WB 068 and WB 070 start and build nativeEx_barebone
(Copy & Expand stops with error message that at least WB 071 is needed. That is ok)
WB 072 and WB 074 do not even start.

Peter

[booty#1]

My first test of WinBuilder 074:

I am sorry Nuno, but I don't see any positive progress within this new version and I have to say that I am in progress of loosing my patience regarding the WinBuilder development:

Since two or three stable versions I tell you that the attachment decryption method is worse. I already posted optimized versions a dozen of times, people are complaining about the execution speed but nothing happens. This all is very very dissatisfying

Just for demonstration for all of you who are asking "Why does it take more than 30 minutes to build e.g. a VistaPE on a high-end machine:
Nearly all files are stored in a 7z archive attached to the scripts. Extracting each of those archives processes the following steps:
1. Reading the attachment section from script into memory
2. Writing the content of the lines into a separate file (.b64)
3. Reading that file back into memory meanwhile it will be processed by the base 64 decoder. The output is again saved into a file (.arc)
4. The .arc file is some sort of simple archive. It contains the attached file, therefore again we read th file into memory and meanwhile uncompress the attached file - a 7z file in case of VistaPE
5. Now we have the .7z file which is again an archive (we love redundancy!!) has to read and process/decompress

I already posted well tested code snippets that eliminate step 2 and step 3 and well reasoned ideas for improving the attachment mechanism, decreasing the decoding marathon to two steps which can run up to a certain file size completely in memory.

Besides this major problems I found some smaller GUI problems which seem to me very familiar:
Select a script, go in edit mode, close edit mode and then try to resize the tree horizontal: The panel on the right moves, but the tree does not resize to fill the gap.

booty#1

[pscEx]

My first test of WinBuilder 074:

I am sorry Nuno, but I don't see any positive progress within this new version and I have to say that I am in progress of loosing my patience regarding the WinBuilder development:

Since two or three stable versions I tell you that the attachment decryption method is worse. I already posted optimized versions a dozen of times, people are complaining about the execution speed but nothing happens. This all is very very dissatisfying

Just for demonstration for all of you who are asking "Why does it take more than 30 minutes to build e.g. a VistaPE on a high-end machine:
Nearly all files are stored in a 7z archive attached to the scripts. Extracting each of those archives processes the following steps:
1. Reading the attachment section from script into memory
2. Writing the content of the lines into a separate file (.b64)
3. Reading that file back into memory meanwhile it will be processed by the base 64 decoder. The output is again saved into a file (.arc)
4. The .arc file is some sort of simple archive. It contains the attached file, therefore again we read th file into memory and meanwhile uncompress the attached file - a 7z file in case of VistaPE
5. Now we have the .7z file which is again an archive (we love redundancy!!) has to read and process/decompress

I already posted well tested code snippets that eliminate step 2 and step 3 and well reasoned ideas for improving the attachment mechanism, decreasing the decoding marathon to two steps which can run up to a certain file size completely in memory.

Besides this major problems I found some smaller GUI problems which seem to me very familiar:
Select a script, go in edit mode, close edit mode and then try to resize the tree horizontal: The panel on the right moves, but the tree does not resize to fill the gap.

booty#1

@Booty!
You are right:
- By better WinBuilder internal functions time of decoding attached files could be reduced remarkably.
You are wrong:
- IMHO, only small necessary files, like user written EXEs etc. should be attached to the script. No third party packages (even if this way of distrribution is licensed). For small files the decoding time is neglectible.

Peter

[MedEvil]

You are wrong:
- IMHO, only small necessary files, like user written EXEs etc. should be attached to the script. No third party packages (even if this way of distrribution is licensed). For small files the decoding time is neglectible.

Peter

So in your opinion, bugs only have to be fixed if they are really really annoying and can't be circumvented by not using the feature?

I agree with booty. Encoding all neccessary files into a script is the best feature of WB, but the handling of scripts in general and the unpacking especialy, could be done in a more elegant way.

For instance, what for does WB load the whole script into ram, if i just want to set a few checkmarks in the interface?

[pscEx]

So in your opinion, bugs only have to be fixed if they are really really annoying and can't be circumvented by not using the feature?

I agree with booty. Encoding all neccessary files into a script is the best feature of WB, but the handling of scripts in general and the unpacking especialy, could be done in a more elegant way.

For instance, what for does WB load the whole script into ram, if i just want to set a few checkmarks in the interface?

First: If you quote, please quote complete sence!

Second: This is not a bug. This is a 'Bad Feature'. With a bug 'strange unexpected things' would happen. But here everything runs (slowly, but) well.

Third: Imagine you write a script to modify / start an ISO: The ISO is a necessary file. Should you include some 100 MB?
Or should you give the possibility to download (once and then cache) the ISO?

Fourth: I thought to speak about attachements, not about general WinBuilder design aspects.

Peter

[MedEvil]

First: If you quote, please quote complete sence!

I may not quoted your complete text, but i did quote the complete sentence!

Second: This is not a bug. This is a 'Bad Feature'. With a bug 'strange unexpected things' would happen. But here everything runs (slowly, but) well.

You may call it what you want, to me everything that isn't working as good as it should, may it be by error or design, is a bug and should be fixed,

Third: Imagine you write a script to modify / start an ISO: The ISO is a necessary file. Should you include some 100 MB?
Or should you give the possibility to download (once and then cache) the ISO?

I would give the chance to download it once. Inside the script!
Strange question for the starter of the 'VistaPE for dummies' thread.

Fourth: I thought to speak about attachements, not about general WinBuilder design aspects.

The root of both problems is the same. Nuno used in both cases the simplest most straight forward way.

[pscEx]

I would give the chance to download it once. Inside the script!
Strange question for the starter of the 'VistaPE for dummies' thread.

You agree to what I suggest!
Second sentence ????????????????????

[MedEvil]

You agree to what I suggest!
Second sentence ????????????????????

Appearantly my humor didn't made it all the way.

I wasn't talking about including a download function in the script.
I was talking about downloading it once, encoded in the script!

[risolutore]

booty#1 you are on the good way, we have to keep it simple as possible, modular, and with native multilanguage support for Vista. The error when risizing the windows depends on the font used Segoe etc that is used only in Vista..

[booty#1]

The error when risizing the windows depends on the font used Segoe etc that is used only in Vista..

I don't think we are talking about the same problem (see the attached screen shot, taken on my Windows XP machine).

@Nuno:
Sorry for my harsh words in my last post, but what I said needed to be said. From my point of view I think the main problem is that "your baby" (aka WinBuilder) is outgrowing you. That is a natural progress and therefore programmers who work at large (and still growing) applications are confronted with this problem earlier or later:
The programmers brain and time is limited, but the application demands more and more resources for implementing new features, fixing bugs, identifying problems and developing solutions...
For "solving" this dilemma there are several possibilities - ranging from "continue as before" (increases dissatisfaction in the community) to publish it as open source. I know that the latter one is not an option for you because of several severe reasons I can not confute, but from my point of view there are a lot of possibilities between those two extreme possibilities I mentioned.

It is my believe that careful opening of WinBuilder will not harm neither you, WinBuilder itself nor the community - just the opposite.

booty#1

Attached Thumbnails

• 

[Draugen]

My first test of WinBuilder 074:

I am sorry Nuno, but I don't see any positive progress within this new version and I have to say that I am in progress of loosing my patience regarding the WinBuilder development:

[snip]

booty#1

in a word: WORD!!! (sorry, bad pun, couldn't resist.)

Seriously: you sum up my greatest frustration with batcher/openbuilder/winbuilder: you see an issue, you point out why it is an issue, and propose a fix - very often of the copy/paste variety - and... nothing (check here for an example of my efforts.) Another example is the implementation of character escapes. I suggestet to nuno over IM to implement standard unix backslash escapes (\" = literal ", \\ = literal `etc) but instead we got the hand-wrenching (on a Norwegian keyboard at least) #$q etc. Sigh.

the solution to this tangled web of code and UI WTFs? Release the Winbuilder code already! Any open license will do. the GPL is one of the most restrictive, and should fit the enthusiastic hacker crowd well. bashrat did so with the Driverpacks many of us know and love, and nothing bad came of it (quite the contrary, IMHO).

I know i'm ranting a lot these days, but as I've mentioned earlier,I am tired of beating around the bush. Nuno, this is not intended as a personal attack. I just fear you may be holding WB back from its true potential from a certain degree of creator's pride (which is understandable). Drop your NIH syndrome a bit, setup a SCM system (dreamhost can setup svn servers almost automagically) and allow restricted write access to the WB code base (read has to be available for anyone and everyone; otherwise a OSI compliant license would be rather pointless). You have skilled developers and hackers who are willing to invest their time and expertise.

Let them.

@Nuno:
Sorry for my harsh words in my last post, but what I said needed to be said. From my point of view I think the main problem is that "your baby" (aka WinBuilder) is outgrowing you. That is a natural progress and therefore programmers who work at large (and still growing) applications are confronted with this problem earlier or later:
The programmers brain and time is limited, but the application demands more and more resources for implementing new features, fixing bugs, identifying problems and developing solutions...
For "solving" this dilemma there are several possibilities - ranging from "continue as before" (increases dissatisfaction in the community) to publish it as open source. I know that the latter one is not an option for you because of several severe reasons I can not confute, but from my point of view there are a lot of possibilities between those two extreme possibilities I mentioned.

It is my believe that careful opening of WinBuilder will not harm neither you, WinBuilder itself nor the community - just the opposite.

And i just finish writing the above rant when i see this post! Guess it's not just me then. I completely and utterly agree.

// martin out.

[phox]

My first test of WinBuilder 074:

I am sorry Nuno, but I don't see any positive progress within this new version and I have to say that I am in progress of loosing my patience regarding the WinBuilder development:

Since two or three stable versions I tell you that the attachment decryption method is worse. I already posted optimized versions a dozen of times, people are complaining about the execution speed but nothing happens. This all is very very dissatisfying

I already posted well tested code snippets that eliminate step 2 and step 3 and well reasoned ideas for improving the attachment mechanism, decreasing the decoding marathon to two steps which can run up to a certain file size completely in memory.

Besides this major problems I found some smaller GUI problems which seem to me very familiar:
Select a script, go in edit mode, close edit mode and then try to resize the tree horizontal: The panel on the right moves, but the tree does not resize to fill the gap.

booty#1

I know i'm ranting a lot these days, but as I've mentioned earlier,I am tired of beating around the bush. Nuno, this is not intended as a personal attack. I just fear you may be holding WB back from its true potential from a certain degree of creator's pride (which is understandable). Drop your NIH syndrome a bit, setup a SCM system (dreamhost can setup svn servers almost automagically) and allow restricted write access to the WB code base (read has to be available for anyone and everyone; otherwise a OSI compliant license would be rather pointless). You have skilled developers and hackers who are willing to invest their time and expertise.

I don’t understand you guys:
Nobody and nothing prevents you from making better replacement for WinBuilder!!!

Keep going Nuno!

Don’t let some skilled developers and hackers to come near WinBuilder.
Keep it under tight control in the future too.

[smiley]

Sorry phox but I think that booty#1 and martin are right. In this community there are so many skilled developers (including Nuno,Peter and booty#1) that can help winbuilder to become a superior tool. In those people I don't include myshelf as I'm neither a skilled programmer nor a delphi porgrammer.

Nobody and nothing prevents you from making better replacement for WinBuilder!!!

Noone intends to create a replacement for winbuilder and noone wishes that to happen. Everyone sees that some times Nuno can't create what this comunity wants so some programmers now offer their help!

[Draugen]

I don’t understand you guys:
Nobody and nothing prevents you from making better replacement for WinBuilder!!!

but why? WB exists and has this thriving community. Nothing will be gained by fracturing it.

Keep going Nuno!

Indeed! but let others HELP!

Don’t let some skilled developers and hackers to come near WinBuilder.
Keep it under tight control in the future too.

ummm... this makes no logical sense whatsoever. more skilled WB devs = more coding = better WB faster. And nuno would still be the lead maintainer of course.

[booty#1]

I don’t understand you guys:
Nobody and nothing prevents you from making better replacement for WinBuilder!!!

Sorry but you don't recognize WinBuilder as it is: It is not just a simple piece of software - it is a software with a large community supporting it. One of WinBuilder's strength is it's community and deveopling a WinBuilder replacement would surely split the community - and this is the last thing I have in mind.

booty#1

[phox]

Too many midwifes bring crippled child!

[pscEx]

Too many midwifes bring crippled child!

I remember times when I led excellent teams!

Peter

[phox]

I remember times when I led excellent teams!

Peter

That is exactly what we have in this forum:

1. Nuno, as author and owner of WinBuilder is Chief Magician,
2. You, as author of XP based Core, are Guru,
3. Jaclaz, as Forum whip takes care of law and order,
4. Galapo, Thunn, and NightMan are Project Managers,
5. Script developers generate scripts and
6. Plebs follows what is happening in the Forum.

Everyone is invited to supply comments, critics and suggestions but:

a. Only Nuno decides what will be implemented in the WinBuilder,
b. Only you decide what should be accepted for Core,
c. Only Project Managers decide how to organize their Projects and
d. Script developers decide about acceptance of script suggestions
but authorize Project Managers to adapt them for their Projects.

That is how I understand excellent team!

[pscEx]

That is exactly what we have in this forum:

1. Nuno, as author and owner of WinBuilder is Chief Magician,
2. You, as author of XP based Core, are Guru,
3. Jaclaz, as Forum whip takes care of law and order,
4. Galapo, Thunn, and NightMan are Project Managers,
5. Script developers generate scripts and
6. Plebs follows what is happening in the Forum.

Everyone is invited to supply comments, critics and suggestions but:

a. Only Nuno decides what will be implemented in the WinBuilder,
b. Only you decide what should be accepted for Core,
c. Only Project Managers decide how to organize their Projects and
d. Script developers decide about acceptance of script suggestions
but authorize Project Managers to adapt them for their Projects.

That is how I understand excellent team!

You are right.
But your description also shows some lacks which are mentioned by Booty and Draugen.

The 'lower levels' should not only have the possibility to suggest enhancements etc.
They also should have the (maybe restricted) ability to change something which is in the responsibility of 'higer level'.

Let me explain with my personal situation:
I wrote a lot ot programs which are included or called by scripts.
All the source code currently are my personal secrets.
(I informed my son, that in case of my sudden death or personal disease, he should send these sources to Nuno)

I would copy all of the sources into a 'WinBuilder source data base'
As Draugen suggested, this database could should be read only for the public, and should be a working CVS for selected persons.

Peter

[phox]

You are right.
But your description also shows some lacks which are mentioned by Booty and Draugen.

The 'lower levels' should not only have the possibility to suggest enhancements etc.
They also should have the (maybe restricted) ability to change something which is in the responsibility of 'higer level'.

Let me explain with my personal situation:
I wrote a lot ot programs which are included or called by scripts.
All the source code currently are my personal secrets.

You and I agree perfectly: the differences are only language.

“Lower levels” are invited to suggest enhancements, but it is
up to you to implement them in your “personal source code”,
or up to Nuno to implement them in WinBuilder.

Nobody should be frustrated if some of his suggestions are
not immediately or at all implemented.

Too frustrated members should start their own forums with
some new WinBuilders.

I would copy all of the sources into a 'WinBuilder source data base'
As Draugen suggested, this database could should be read only for the public,
and should be a working CVS for selected persons.

Peter

It is up to Nuno to found “WinBuilder source data base”,
if at all, and decide who should be authorized to approach it.

[booty#1]

a. Only Nuno decides what will be implemented in the WinBuilder,

Hi phox, I have to sam that you are very very idealistic.
The problem is that Nuno does not only have to decide what will be implemented - he has to implement it.
If you would be a programmer you would know that this are two very different thinks: decide and implement.
Deciding is usually not too complicated and can be completed fast but implementing it takes a lot of time.

booty#1

[phox]

Hi phox, I have to sam that you are very very idealistic.
The problem is that Nuno does not only have to decide what will be implemented - he has to implement it.
If you would be a programmer you would know that this are two very different thinks: decide and implement.
Deciding is usually not too complicated and can be completed fast but implementing it takes a lot of time.

booty#1

Thank you for the lesson in programming:

I did not know the difference between decide and implement!
I feel very very relieved now.

You are overlooking just one small detail:

Nuno does not has to implement anything,
except what he feels like or finds necessary!