157 replies to this topic

[Brito]

You're a true pro when it comes to this sort of debugging!

Please replace the current beta with this new binary:  WinBuilder071_Beta4a.zip   805.99KB   382 downloads

Hope this time it behaves more nicely, thank you for the very detailed logs and pacience..

Edited by Nuno Brito, 11 June 2007 - 08:09 PM.

[pscEx]

You're a true pro when it comes to this sort of debugging!

Please replace the current beta with this new binary:  WinBuilder071_Beta4a.zip   805.99KB   382 downloads

Hope this time it behaves more nicely, thank you for the very detailed logs and pacience..

The qEmu boot screen looks ok now.
So it can be assumed that the bug is fixed.
Let me do some more tests.

Peter

[Brito]

I will get my hands improving the read INI procedures right now..

[pscEx]

I will get my hands improving the read INI procedures right now..

Before starting, pleas think about this.

Peter

[Brito]

New beta uploaded!

This newer binary has addressed the bug on regwrite which kept registry keys from being properly added.

[pscEx]

Maybe it is new, maybe I did not see before:

I have the code:

ShellExecute,Open,"#$q%ProjectTemp%\wbVersion.exe#$q","#$q-F:%ProjectDir%\Script.project#$q -S:Variables -K:#$pWBVersion#$p"

which does not work correctly.

The log shows:

Shellexecute: [Open] using: ["%BaseDir%\Temp\nativeEx_barebone\wbVersion.exe"]

I need the parameters!

Peter

[Brito]

Please try this binary:  WinBuilder071_Beta5a.zip   805.97KB   347 downloads

[pscEx]

Please try this binary:  WinBuilder071_Beta5a.zip   805.97KB   347 downloads

I now get an error, no execution


Peter

[Brito]

Annoying bug, it was added while recoding shellexecute - I will work on it properly once I get home..

[Brito]

A new revised shellexecute has replaced the one found on the previous beta 5..

[thunn]

thanks for catching that bug!!
.(.....)
(X) (X)
....U
....~

[Brito]

Beta 6 - special edition..

Why a special edition?

Because it is likely filled with new bugs and it is only recommended to people who like challenges..

(consider yourself warned..)

This beta contains a lot of changes since the last posted beta, most of them related to speed improvement and memory leak fixes.

It should run with same files and definitions as a direct replacement to the previous betas, but please try running a few projects and check both the qemu emulation and logs to see if it works ok.

Resumed log of changes:

- Removed an unneeded setting which always wrote a locked=true value on the [main] section
- Recoded interface, file search/filter and settings to load faster.
- Bugfixed error message when selecting to show log after running a project.

Tried to removed out most of the new possible issues, but surely some have passed. If this beta works good enough than it will be posted on the first topic.

Some things are still left to further improve - for example: when a user clicks on a very large script it will still load it to memory slowing the interface a bit (still need to look further on why this happens) and optimize the encode/decode functions which should also be done whenever some time is available to work it.

Hope you have fun and thank you for testing!!

 WinBuilder071_Beta6.zip   790.26KB   379 downloads

[booty#1]

Beta 6 - special edition..

Ok, here are my first experiences with this beta:

• Directly after starting WinBuilder an Information Dialog saying "215" shows up (missing localization?).
• Building my adapted VistaPE version (based on 008) the memory usage is usually between 18MB and 20MB, once 40MB + executed programs of course. The built VistaPE version is OK on first impression - no preblem detected. Runs just like the one created by 071beta5.
• Attachment encoding hasn't changed (two temporary files, encoding takes ages)
• In edit mode on the interface builder page the edit mode closes directly after adding a control
• Selecting a script of 45MB without interface section - it takes about >15 seconds with 100% cpu of one core on my system (C2D E6600).
  The several first times I thought WinBuilder crashed and terminated it. I can see in FileMon that WinBuilder read the script in blocks of 128 bytes. This value is very small, if possible I would use a larger value, this should speed up the read process. Memory usage doesn't increase much on loading. After once reading the complete file it reads "randomly" from different offsets within the file and reads up to 10K. I checked the offsets and they are in the middle of the encoded file - is this an inteded behaviour?
• On enabling/disabling this script the script is loaded completly into ram (blocksize on reading 65k). The meory usage on loading the 45MB script is 120MB, before and after 14MB -> 106MB memory used for a 45 MB script.

Besides the enabling/disabling issue the the beta has really a small memory footprint. WinBuilder has made IMHO a large step towards better usability on low- and mid-end systems.

In conclusion: Nice work Nuno

booty#1

[Brito]

Thanks for the quick testing!

I'll try to reply following the topic order:


1. It was a control message to ensure that all scripts we're correctly counted before and after the code changes, no special relevance.

2. Will keep testing with bigger sized projects, this time I focused on the interface portion.

3. encoding is unchanged, but modified decode to make script loading on the main window faster, next step should be removing the two temporary files (if possible)

4. A bug to be solved.

5. Will repeat your described steps until it works better.

6. That part still uses default delphi tools, I still need to write some functions to also write on INI text files.

Glad to see that most of these bugs are related to the new "heavy" sized scripts support, will keep working on it.

[smiley]

I just tested decompression . It is very fast

However I found a new bug in winbuilder.
I have attached in a script a 30Mb file. Hile editing its interface, even resizing a control took 3secs(in a good computer). While doing this,I had process explorer open and saw that while doing this winbuilder open and closed the script 4 times .

Another problem that I found was that winbuilder has still a serious handle leak. I saved this file with process explorer and shows that winbuilder forgets open all the subfolders of its projects. The attached file shoes all the open handles that winbuilder has. The handles of the folders are in the middle of the file
 WinBuilder.exe.txt   9.48KB   584 downloads

PS: While attaching/expanding files to/from scripts, winbuilder freezes. Can you make this procedure multithreading?

[Brito]

Smiley, thanks for finding this open handles bug - I thought they had already been all solved.

I've optimized the functions to read ini files, but I need to code a completely different approach to correctly write them.

At the moment the optimized INI function will only read one at a time, next step should be using this method to retrieve each key inside the section and this way avoid open file/close file just to read a single value.

Funny enough that even using this non-optimized method, it will still be much faster that traditional INI methods..

Please try this new binary and repeat the open handles test to see if it was solved as expected.

--------------------------------------------------------------
booty#1, the bug that closed edit mode when inserting new objects was also corrected.

---------------------------------------------------------------

Download Center is now based on IE - this will of course mean that Windows based machines need to have IE installed, but I will also likely leave the old external download method as option for the cases where IE is not available (some nlite customized installations, Win95, ReactOS and wine for example)

In exchange we inherit support to proxy connections from IE itself which should solve the problems with connecting to the download servers and avoid firewall warnings while downloading using non-recognized ports. Should be compatible with all Vista UAC restrictions and XP built in firewall. (only tested on XP) - as long IE works, wb should also get online.

Also removed the old ping method to test if a server is available and replaced it with a test to check if the updates.ini is correctly downloaded or not.

---------------------------------------------------------------

This should hopefully become the base for the next beta and stable version if projects can be downloaded and run without noticeable bugs.

 WinBuilder071_beta6a.zip   806.01KB   326 downloads

Edited by Nuno Brito, 24 June 2007 - 02:25 PM.

[booty#1]

3. encoding is unchanged, but modified decode to make script loading on the main window faster, next step should be removing the two temporary files (if possible)
4. A bug to be solved.
5. Will repeat your described steps until it works better.
6. That part still uses default delphi tools, I still need to write some functions to also write on INI text files.

Hi Nuno.

3. -> Removing the second temporary file will be hard with the current compression algorithm but the first can be done (as I have showed). My posted source code isn't well commented, if you have questions regarding it, just contact me.
4. -> In Beta6a this bug is solved from my observations
5. -> (large script without interface) Well I would at least modify the script editor to always insert an Interface section at the beginning into the script file
6. -> (enabling/disabling scripts) From my point of view it would be the easiest way to put those frequently changing entries into an separate settings file (is enabled and interface values). Values in the settings file "override" those in the script, the script files could remain static. From my point of view it would be the "easiest" (less coding complexity) solution and it would be even backward compatible with old WinBuilder version if you do not publish the settings files.
Additionally this which would make it much more easier to distinguish between an old and an updated script file - but we already had that discussion in another thread.

I found one new minor bug, regarding a newly added FileBox item with a default value. This default value sometime disappears if you switch to another script and the back to the edited script. But that is really a marginal bug.

booty#1

[MichaelZ]

This should hopefully become the base for the next beta and stable version if projects can be downloaded and run without noticeable bugs.

Hi Nuno,

WB 071 Beta 6 gave me at start (and I think after downloading files) a dialog with some 'magic' number. But now Beta6a has some serious problem on my computer. Instead of displaying the magic number it gives the error message

'' is not a valid integer value.

After klickin OK nothing happens anymore

Many Greetings
MichaelZ

[was_jaclaz]

Download Center is now based on IE - this will of course mean that Windows based machines need to have IE installed, but I will also likely leave the old external download method as option for the cases where IE is not available (some nlite customized installations, Win95, ReactOS and wine for example)

In exchange we inherit support to proxy connections from IE itself which should solve the problems with connecting to the download servers and avoid firewall warnings while downloading using non-recognized ports. Should be compatible with all Vista UAC restrictions and XP built in firewall. (only tested on XP) - as long IE works, wb should also get online.

PERSONAL opinion (and rant):

I don't care what we inherit.

This, in my view, equates to admitting that IE has some use, besides occupying large amounts of HD space, which I thought was the exact opposite of the (unspoken of) basic assumption that started the Winbuilder project, i.e. that IE is just a badly written, bloated browser, unneededly intertwined by perverts programmers and marketing strategies into an otherwise good core, that can ANYTIME be removed and substituted by BETTER browsers, like Opera or Firefox.

What will be next, instead of a .html log, a MS XML:
http://ktn.blogsome....rietary-format/
that can only be e-mailed through Outlook Express?

Using IE should be an (unneeded) option, not the default.

jaclaz

[pscEx]

PERSONAL opinion (and rant):

I don't care what we inherit.

I do not really want to tell that I rant, but I was rather astonished when I saw 'Download Center is now based on IE'

I'm using Firefox since (???) and I do not know whether the IE based download center will bring some new issues.

Let me observe the download mechanism next days, and I can tell more.

Peter

[MichaelZ]

WB 071 Beta 6 gave me at start (and I think after downloading files) a dialog with some 'magic' number. But now Beta6a has some serious problem on my computer. Instead of displaying the magic number it gives the error message

After klickin OK nothing happens anymore

Sorry, but the above statement is incorrect. The issue is already in WB 071 Beta 6 and is not introduced with beta 6a.

The error happend after I moved my other scripts back into the VistaPE project folder (after downloading a new WB and/or VistaPE I always do one build with only the standard scripts). At the same time I downloaded beta 6a so I thought it's a problem with the very last modifications.

WB 071 Beta 1 accepts my other scripts but beta 6 does not anymore. I did not use any betas in between. Tomorrow I will isolate which script confuses WB so much.

Many Greetings
MichaelZ

[Brito]

Hi Nuno,

WB 071 Beta 6 gave me at start (and I think after downloading files) a dialog with some 'magic' number. But now Beta6a has some serious problem on my computer. Instead of displaying the magic number it gives the error message

After klickin OK nothing happens anymore

Many Greetings
MichaelZ

This sounds like some number is not being translated properly along the way. I would guess that this might come from the interface section.

If it's at start up then the first file to be displayed will be script.project from the first listed project.

Please try downloading a fresh project on a new folder just to move away the chance of possible file corruption.

If this error box appears again, please post all your steps and I will reproduce to start debugging myself.

Thanks!

---------------------------------------------------

Jaclaz and Peter - I know that IE is what most people label as evil since it comes from MS, but I try to view it as tool just like any other that has the advantage of being present by default on the vast majority of machines where our projects will run (Windows XP/Vista platforms).

Could we include Opera? I don't know, but I know it would likely add around 8Mb to the standard distribution which is smaller than 900Kb, or perhaps use firefox and add a bit more in overall size and ask users to install an activeX component and having to code by hand all the support for this browser. (which could take a long while for this simple task) and wouldn't likely bring a compatible solution for x64 XP/Vista editions.

IE has the advantage of not needing any installation procedure, already has activeX and well supported components which allows wb to be used on schools and universities where only guest accounts are used or under firewalls which allow no exceptions besides the already available browser.

Plus that we share the same proxy connections so that people can just get connected without effort.

Most users don't even know which type of proxy they use let alone know user and password details on public access machines.

I already escaped coding in .NET to avoid oversized libraries, and I understand your reasons but do you have a better alternative that works under these restrictive conditions?

Maybe someday another solution appears that can effectively replace the one provided by this overgrown corporate evil, but in the meanwhile - please let me see this solved and move on to more important issues in other areas..

Hope this method brings the needed stable network connectivity and start solving this long time question about issues regarding the download center not working under restricted conditions or questions about why it uses strange ports signaled by firewalls.

[euhenio]

My opinion.

WB problems:

1.Unicode
2.RegDelete(value),RegRead(binary value)
3.....
.......
.......

[TheHive]

Beta 6 - special edition..

On this beta there are no tabs when you first run it.

[was_jaclaz]

Nuno,
just wishing to clarify some points:
1) I am not against IE because it is from Microsoft, MS, like I guess all software producers, have made very good things and very bad ones, the NT core has proved in more than 13 years (yes, the real NT core dates back to circa 1993) to be very good, stable and rather fast, IE on the contrary, and its companion app Outlook Express are the two single programs that due to flaws in design, intertwining with the OS, undocumented or poorly documented features have been the cause of the greatest numbers of headaches to technicians, SysAdmins and users in the last 10 years, having caused an unbelievable number of security breaches, data and system corruption and what not.
I have a system that has been switched on 24/24 7/7 for the last 4 (four) years, connected to the Internet, that is used mainly for accounting but also used daily for e-mails (sending and receiving) and for internet browsing that had 1 (one) case of a virus entering (and promptly neutralised by the anti-virus), with NO firewall whatsoever.
I have a Win2K one, with IE and OE stripped, that in 3 (three) years with the same use and setup had none.
Various experiences with similar setups with XP (with firewall enabled), "as is" i.e. with IE and Outlook Express respectively as browser and e-mail app, had several breaches and cases of data corruption in a few months of use.

So, it is not that I do not like IE because it is from MS, I do not like it because it is a possible and probable security breach.

2) For exactly the same reasons I always expressed my opinion against:
a- Winbuilder going on-line by "his own will"
b- Winbuilder opening or accessing ports
c- Winbuilder having inside scripts unknown apps encoded - possibly "transparent" to anti-virus scanning
d- Winbuilder .scripts lack of documentation

3) And of all the potential security concerns of IE, ActiveX is the first one!


4) As said elsewhere, it is, in my view, the distribution model of Winbuilder that is flawed, the whole idea of a central, unique repository is wrong as I see it, and before anyone comes out asking for a better alternative, I have NONE, excluding the good ol' way of a number of downloadable files that can also be mirrored by volunteers, maybe it is not "pretty", nor it is "bleeding edge", but it has proved to work for the greatest number of projects for the last years.


5) I know that probably if we go the way above outlined we somehow "deprive" users of a "one-click-does-it-all" experience, but quite frankly I cannot see why one cannot download with ANY app he has, via http or ftp, one or more self-extracting .7z archive and run it

jaclaz