89 replies to this topic

[littlepoor]

CommandLine
.\WinBuilder_110520.exe /run=.\Projects\Win7PE
Access violation at address 0058E8BB in module 'WinBuilder_110520.exe'. Read of Address 00000688.
OK
" is not a valid integer value.
OK

After that loading the projectbrowser without starting the buildprocess.
(WindowsXP64bit)

last working version 80.0.3.0
Any clue why this is broken ?

[larioteo]

I got the same error it is caused due to interface configuration, delete it and it should be gone.

[littlepoor]

I got the same error it is caused due to interface configuration, delete it and it should be gone.

Where exactly do i find it? Is it a global configuration entry, project dependent or a special file somewhere in the directorystructure?

[larioteo]

The PostConfig Script had a bad scrollbox, i removed it and recreated it with the interface builder.

I hope ChrisR will fix this issues in future, ... it is a nice project.

[littlepoor]

i actually have the problem with Win7PE_SE project
with
.\WinBuilder_110520.exe /run=.\Projects\Win7PE\Finalize\5-iso-burner.Script
i got the same error
i haven't found any script that is working

with version 80.0.3.0 i have no problems at all

[larioteo]

Open the script and cut the Interface area than save it, it should solve the error, copy the interface section to a temp file and rebuild it with the new winbuilder. There are some scripts that aren't working well, no idea why, but a interface rebuild helps me.

Edited by Darijo, 26 May 2011 - 02:33 PM.

[littlepoor]

Open the script and cut the Interface area than save it, it should solve the error, copy the interface section to a temp file and rebuild it with the new winbuilder. There are some scripts that aren't working well, no idea why, but a interface rebuild helps me.

even with a newly created "empty" script i get this error

[ChrisR]

The PostConfig Script had a bad scrollbox, i removed it and recreated it with the interface builder.

I hope ChrisR will fix this issues in future, ... it is a nice project.

There is no scrollbox in postconfig ! and Thanks for nice words .
Anyway, I tried to remove the Radio Group and recreate it and by comparing with the original one in hexa, I do not see any difference on the interface section.

The project was tested, retested since month in WB 80, as Admin, I could not validate the good compatibility.

[larioteo]

@nuno&psc

is there any statement here? the new interpreter is realy fast, and this release should be released soon, i don't want to miss this wonderful speed.

@ChrisR your latest release and the latest winbuilder, worked for me, yesterday, with System,Comp80,Off I reduced it as aj_jo it did. (the tiny pe)

[Brito]

is there any statement here? the new interpreter is realy fast, and this release should be released soon

The main goal is assuring stability and defect correction until the next week. After that it should be ready for release.

It is impossible to iron out all the reported defects and it is nevertheless a good improvement when compared to the 080 released a year ago.

[larioteo]

I think if the build time reduces over 30% to 40% percent i would at my own change every script, the main goal for me is, a builder which builds fast and no which supports scripts from over years ago.

But you are the developer, i remember what happend as microsoft released vista, everything compatible everything better, but it was still to slow, and more than a half dont wanted to use it.

If the interpreter need some updates to be faster, why not?

I think it will be less work for developers to improve there scripts for the new interpreter, faster builds means also faster debugging.

Win7PESEtiny with compability mode 35 Minutes
WIn7PESEtiny without compability mode 17 Minutes, there is than a much more time to concentrate on the PE related bugs, rather than on the others. In this case it is more than 50% faster.


It is only my mention please don't critizize it, if the new builder will not have this improvement i will rather use the faster beta release.

Edited by Darijo, 27 May 2011 - 08:57 AM.

[al_jo]

Win7PESEtiny with compability mode 35 Minutes
WIn7PESEtiny without compability mode 17 Minutes, there is than a much more time to concentrate on the PE related bugs, rather than on the others. In this case it is more than 50% faster.

Hi.
With 12 really necessary scripts it’s ≈ 5 minutes here. Final ISO = 185MB
With the 12 + 60 app scripts it’s ≈ 10 minutes. Final ISO = 400MB
Using WB81.0.1.197 and this updated Win7pe_tiny/micro project:
http://al-jo.99k.org..._SEmicrotiny.7z

[larioteo]

Yes i believe you, on my machine it tooks a little bit longer

I have an P4 with 2.4 GHz and a matrox graphics card, very slow, the new winbuilder is on my machine like a rocket, compared to the old, i think it should run on slower machines also fast.

Maybe in 10 years i will buy a core i7 or so, when i get it for 10 dollars

Edited by Darijo, 27 May 2011 - 01:00 PM.

[al_jo]

Sorry, forgot my spec

CPU: AMD Athlon II X3 425 Processor 2700MHz (L1 cache: 64.0 Kb, L2 cache: 512.0 Kb, L3 cache: 0 Kb) Ext.clock: 200 MHz

RAM: 2.50 Gb (2 618 860 Kb) A0: 2048 Mb(Other,Unknown,EDO,155 ns) A1: 1024 Mb(Other,Unknown,EDO,155 ns)

GPU: ATI Radeon 3000 (700.0 Mb): 1920 x 1080 - True Color (32 bit)

Not very much power comparing to what 10 year old kids have today to play with…

Ps. Also have an old PC with P4 Prescott 3000Mhz, 1GB RAM, will try & measure the time on that machine later on.

[Brito]

If the interpreter need some updates to be faster, why not?

Don't get me wrong, I like speed. The problem is that we need to minimize changes between each version so that we can use current projects without need to rewrite them. This is a volunteer effort so we need to maintain compatibility with past works as much as possible.

Speed and stability are important attributes. Between both, stability is given priority and then speed comes next whenever possible.

[paraglider]

Seems to be bugs in the handling of folder links. I have a folder.project that contains:

[Links]
Projects\Addons.PG\*.*

Files without extensions in a subfolder of a script don't follow the script in the tree. Hence you get:

Attached Thumbnails

• 

[paraglider]

Also scripts in the root of the linked folder don't show at all.

Here is what I get if I use a file system hard link to link the 2 folders ( note still get the 3rd spurious folder for the files without extensions ):

Attached Thumbnails

• 

[sbaeder]

Don't get me wrong, I like speed. The problem is that we need to minimize changes between each version so that we can use current projects without need to rewrite them. This is a volunteer effort so we need to maintain compatibility with past works as much as possible.

Speed and stability are important attributes. Between both, stability is given priority and then speed comes next whenever possible.

So, could we perhaps ask for the "default" to be "mostly" compatible, and for strict compatibility, provide the switch? Or to put it plainer, I would like to see the default be "SYSTEM,COMP80,OFF", and if an older project needs it, that they set it "ON" in their project file.

Bottom line, not a big deal, because it's maybe just as easy for newer projects to set it "OFF"...As long as it's not burried deep in the docs somewhere...

Speaking of docs, a proper "release" should probably have a cleaned up set of docs that reflect all the commands in the engine, and it might be a good time to clean up all the things just in the release notes...Any thought son that process and how to manage it so we get a good set of web pages, chm file, etc.????

Scott

[pscEx]

So, could we perhaps ask for the "default" to be "mostly" compatible, and for strict compatibility, provide the switch? Or to put it plainer, I would like to see the default be "SYSTEM,COMP80,OFF", and if an older project needs it, that they set it "ON" in their project file.

Bottom line, not a big deal, because it's maybe just as easy for newer projects to set it "OFF"...As long as it's not burried deep in the docs somewhere...

Speaking of docs, a proper "release" should probably have a cleaned up set of docs that reflect all the commands in the engine, and it might be a good time to clean up all the things just in the release notes...Any thought son that process and how to manage it so we get a good set of web pages, chm file, etc.????

Scott

IMO the optional switch "ON" is not really necessary.
When you search the ( C )API and some projects for all friendly comments like "Stupid WinBuilder development", "exbuilder" etc, you'll see that within some minutes of scripting the "compatibility" issue was forgotten.

Peter

[larioteo]

Do you mean they activating compability mode without the knoweledge of the users? Thats bad, the capi is dying in my project, the most useless feature is readenv, which is of course overwritting every set variable in each script, why is something like that neccessary? i remember there was in the past a problem with that but nowadays it is only wasting building time,

The best thing is, the 3 scripts searching for tools if they arent available, and i think it would be better to integrate them fix, there would be almost no problems anymore, if microsoft or every else allows to use it, than we can use it without any bad thinkings.

By the way the preconfig script is shrunken to 5 rows, interesting, isn't it. I know there are a lot of checks behind, but i remove everything uneccessary, and it builds? To much workarounds arent good for the end user. The script only mounts the images yet, the variables thing is automatically set in the main configuration and the best thing the tools that are needet are also integrated FIX.

Every Project should have a debuglevel integrated, if it is as example set to medium or high, more options for developers will be setable, if not, the user can only see and set, what is possible, no options to kill the build. But everyone have his own ideas and will force them, as i do.


What i am wondering is the 100 redirection way for every possibility in the capi due to architecture differences and so on, that is the wrong way i think.

The worst thing is the readenv is a little bit slowing down the whole project, after removing all things, my project is starting copying files after 5 seconds, isn't that good? the best thing within this 5 seconds all folders are also already created, and that on my slow machine.


After that all i will create a overide "API" function wich will eliminate such things from everyscript, and all neccessary things will be loaded before project starts, for every script, but enough for today it is weekend.





We must realize that microsoft changes software and old things that sometimes worked, doesn't work anymore, is it realy so hard to provide scripts for different PE's? No i think not, if i wont seven than i also dont wont hundrets of checks and sets to check architecture and the source type and and and A everything combining api only blows up after a time and will cause more compability issues than the builder itselfes

Edited by Darijo, 28 May 2011 - 06:39 PM.

[larioteo]

Do you mean they activating compability mode without the knoweledge of the users? Thats bad, the capi is dying in my project, the most useless feature is readenv, which is of course overwritting every set variable in each script, why is something like that neccessary? i remember there was in the past a problem with that but nowadays it is only wasting building time,

The best thing is, the 3 scripts searching for tools if they arent available, and i think it would be better to integrate them fix, there would be almost no problems anymore, if microsoft or every else allows to use it, than we can use it without any bad thinkings.

By the way the preconfig script is shrunken to 5 rows, interesting, isn't it. I know there are a lot of checks behind, but i remove everything uneccessary, and it builds? To much workarounds arent good for the end user.

Every Project should have a debuglevel integrated, if it is as example set to medium or high, more options for developers will be setable, if not, the user can only see and set, what is possible, no options to kill the build. But everyone have his own ideas and will force them, as i do.


What i am wondering is the 100 redirection way for every possibility in the capi due to architecture differences and so on, that is the wrong way i think.

The worst think is the readenv is a little bit slowing down the whole project, after removing all things, my project is starting copying files after 5 seconds, isn't that good? the best thing within this 5 seconds all folders are also already created, and that on my slow machine.


After that all i will create a overide "API" function wich will eliminate such things from everyscript, and all neccessary things will be loaded before project starts, for every script, but enough for today it is weekend.

[Wonko the Sane]

IMO the optional switch "ON" is not really necessary.
When you search the ( C )API and some projects for all friendly comments like "Stupid WinBuilder development", "exbuilder" etc, you'll see that within some minutes of scripting the "compatibility" issue was forgotten.

Peter

Poor dead horse , still beating it.





Wonko

[pscEx]

This horse gets his charity:
Don Quijote G... and Sancho L... Pansa's
Peter

[paraglider]

The stated reasons for this release:

1) Ensure compatibility with existing projects
2) Fix bugs

The default option is thus correct. After projects owners have verified that their projects work with the fast option or have made the necessary changes then they can add the setting.

What is missing however is a good description of what the fast option does and how it could introduce compatibility problems.

[pscEx]

What is missing however is a good description of what the fast option does and how it could introduce compatibility problems.

Not officially, just as my personal explanation for a friend, after I decided to stop WB development:

In WB 081, variables are replaced in a binary search, rather than using a linear search like in WB 080 and before.
Here the (currenty possible only in older WB, never in an 'established' compiler like C++) ability to change constants (e.g. %IsoFile%), is a bit contraproductive.
Also to use variables w/o the '%' as macros, is a bit contraproductive.

As far as I remember, I posted this in the "release notes" of 081 RC1.

Peter