193 replies to this topic

[Brito]

Hi Eye0,

 

I've followed your instructions and they work from my NVDA installation well.

 

I'm using Java Access Bridge version 2.0.2 from Oracle that others can download at http://www.oracle.co...oad-354311.html

 

My machine is a Windows 7 SP1 running at 64 bits.

 

Being able to replicate is important, now I will improve the logs of wb to work better with NVDA and make this support available by default.

 

[eye0]

  Hi, Nuno! I checked out your recommendations.
If I move the file "WindowsAccessBridge.dll" from the "System32"  to any folder,
accessibility features stop working.
If you load any screen reader, WindowsAccessBridge.dll can not be removed.
Unlocker indicates executables NVDA or Jaws.
From these experiments, I concluded that this file is needed for screen reader interaction with the environment Java.
On the Oracle Web site is given limited information on manual installation of special features.
jre-7X already contains these modules inside.
Also in jre-7X is a utility JabSwitch.
Special features include the following ways:
In Windows 7 and Vista with the control center special features
;using the control panel applet, Java (all Windows),
;with the utility JabSwitch from the command line.
These methods do not suit us. It remains only the manual method.
Last Java Access Bridge vers.2.0.2 in ZIP - archive is the link:
http://www.oracle.co...oad-354311.html
  Detailed guide to the manual activation in Russian I found here (translated by Google):
http://translate.goo...n&safe=off&sa=G
  I hope that this information will be useful to you. Thanks!

[eye0]

I'm sorry. ;For some reason your last post displayed to me late.
;We have provided you with the same information.
;I'll check on WinBuilder jre-7X.

[farzad_Oscar]

Hi

I have download the winbuilder

I use install win7pe

Install AusLogicsDiskdefragPortable

Install AmmyyAdminPortable

Install FileZillaPortable

Install FreeCommanderPortable

And mount win 7 msdn source in my virtual drive and use this command in win builder : Source H:\

And build

Problem is here . that programs I have downloaded should be part of win7pe project??? or not ? when I use the image there in noting in that … 

[pscEx]

There are two steps to add a plugin to a project.
1. Install it. You already did so.
2. Select it for including in the build: In the GUI type "config win7pe" <return>. Then select it in the formular.

Peter

[Wonko the Sane]

Then select it in the formular.

What is a "formular"?

 

Wonko

[misty]

I have not actually used the new Winbuilder - yet! I plan to do so in the future when I have a little more time on my hands. Who knows, if I can figure out the scripting language I might even write a project or convert an existing one.

I don't want to have or start pointless arguments about which Winbuilder might be best. For those interested in some of my views about previous Winbuilder projects in general see here. WinBuilder is a method of automating/scripting - it's up to individual projects how the WinBuilder engine is actually used. I suspect this also applies to the new WinBuilder.
 

....
This was the first edition of a new generation, now it is time to start improving.

Now that I have establised that I haven't used it I'm going to stick my neck out with some questions/thoughts/observations (and possibly mad ramblings) - based on other posts in this thread and my own experiences creating boot disks using a number of tools (notepad.exe being one of them). I might even be able to contribute to starting to improve it!

I don't understand (or even need to understand) the discussion on Java and the security implications of using it. I personally choose to trust Nuno based on my own experiences of using his applications in the past. Lets face it winbuilder 082 could be used to seriously mess up a system if someone wanted to design a project/script to do so. Whilst I trust Nuno I am not sure that I would extend this trust to individual projects - however this applies equally to previous winbulder projects too!
 

....a few notable "followers" of popular wb projects messed up a simple standard way of writing app scripts for the sake of "betterness". In a single stroke hundreds of app scripts were broken after having worked for years across different projects, despite even using the same engine underneath. ...

....the so called common api / macro library is a nightmare and as you say the owners delete commands whenever they feel like it. I complained bitterly when they deleted the registry commands thus breaking about a hundred of my private scripts. However that is totally irrelevant to the new winbuilder and there was no need to bring old history up here yet again.

Is the new Winbuilder intended to introduce (enforce?) a common syntax to be used across all projects? If the answer to this question is yes, then good luck. And I am not being sarcastic - I really do wish you good luck and sincerely hope that this is achievable. Having a program script (plugin) that works across multiple projects would be a godsend for developers and (more importantly) end users - I just do not know if this is possible and will come on to the possible difficulties and reasons why later. To achieve any kind of common syntax you will need to provide some documentation - and the sooner the better so that the ground rules can be established before too many "Plugins" are written.

I suspect that this might not go down too well, but I would personally recommend introducing a system whereby projects/scripts/plugins should be "certified" or "approved" to ensure that some minimum standards and some kind of compatibility can be achieved. Any man and his dog can currently produce a project and or/program scripts using a legacy version of WinBuilder - I'm speaking from personal experience here as I have! This can be very confusing for the end user. Particularly as there is no guarantee of scripts working across projects and generally a lack of information about available options in some of the project scripts - no fault of Winbuilder as it is after all just the instrument being used to meet the end result. The new Winbuilder however give us an opportunity for a new beginning - a fresh start.

For developers - having a plugin/project certified as "WinBuilder Approved" could be an accolade to strive for. This would not stop other people producing their own projects/scripts/plugins - it would just ensure that that they are compatible if the author wants "Winbuilder Approved" status. I am not trying to be elitest, I just do not see any other way of ensuring some kind of WinBuilder "Standard". Winbuilder is a versatile tool and the two projects that I have personally developed have probably been completely incompatible with all existing scripts. In my defence I didn't even know that there was any kind of "simple standard way of writing app scripts" and have used a fantastic tool to meet my own needs. There is no harm in this approach now or in future and no way of stopping this due to the inherent versatile nature of WinBuilder. Just don't expect the resulting project/plugin to be "Winbuilder Approved".

As a starting point I would insist that any projects just work using the default settings. Knowing that a particular project has been "Winbuilder Approved" should hopefully give new users the confidence to give a project a go. The devil is in the detail - without adequate testing there is a risk of failed builds and consequently frustration and abandonment of not just the project being tested, but WinBuilder as a whole. Trust me - I've been there.

From an administrative point of view this has implications in terms of who will test and approve these plugins/projects and who will decide on approving them. This is however a large community and I would assume that there are enough people willing to volunteer for testing. Obviously there would need to be some kind of testing methodology to ensure consistenty.

To ensure any kind of future compatibility some consideration needs to be given towards a common syntax now. A brainstorming session would be useful. My own suggestion would be for consideration to be given towards having a list of approved "cores" that each plugin can be checked against - then any special commands for that particular project/core could be met.

At the present time I can think of at least 5 different "cores" - WinPE1x/2x/3x/4/5. Each with two distinct processor architectures - so at least 10 variables to cater for. Now here is one of my biggest issues with existing scripts. DEPENDANCIES. Or more accurately the lack of testing to ensure that dependencies are accurately checked. Part of the problem is that some programs might currently work in one project because of a different script that is also being used, or the core files simply being different, and a dependancy unknowingly being there. Take the same script to a different project with a different set of core files, or uncheck an unknown dependency in an existing project and you are up the creek without a paddle!

To ensure compatibility a core needs to be agreed upon as a development platform - in WinPE 2/3/4/5 this could simply be an unmodified WAIK build. If we can isolate the dependancies so that a program works on the most basic core file set then we can be more confident about them working in individual projects using the same core.

Using the legacy WinBuilder syntax this could be something like...
 

[process]
If,%CORE%,Equal,WINPE1x,Run,%ScriptFile%,WINPE1x
If,%CORE%,Equal,WINPE2x,Run,%ScriptFile%,WINPE2x

[WINPE1x]
Message,"This application does not work in WINPE1x. Sorry..."
Exit,"This application does not work in WINPE1x. Sorry..."

[WINPE2x]
If,%ARCHITECTURE%,Equal,x86,Begin
  command
  etc.
End
If,%ARCHITECTURE%,Equal,x64,Begin
  Message,"This application does not work in a 64-bit environment. Sorry..."
  Exit,"This application does not work in a 64-bit environment. Sorry..."
End

Just some things to think about.

Regards,

Misty

[Wonko the Sane]

Hmmm.

 

What about the idea of additionally adding the need for a digital certificate, which will be issued only after the payment for the expenses (which could be established as a yearly forfait) for the trifling sum of US $ 500?

 

No, wait, this is not actually a new idea :

 

To Increase Downloads, Instill Trust First

Learn how code signing mitigates the risks of transferring code over the Internet or wireless networks, as well as allows end users to take advantage of the ease and convenience of content distribution without worrying about security consequences.

 

http://www.symantec....ft-authenticode

 

And no, it is not really-really new even within Winbuilder (though the subscription was free - as in "free beer", NOT as in "freedom"):

http://reboot.pro/to...t-restrictions/

http://reboot.pro/to...ript-integrity/

http://reboot.pro/to...-certification/

 

This approach ended up last time in a lot of people using old engines capable of burning *any* fuel, as opposed to faster engines very picky on the fuel burned and coming from a single source.

 

Mr. Ford has - as said here - won his battle:

http://reboot.pro/to...ty/#entry176716

but the citizens are not having particular advantages from this.

 

 

Wonko

[Brito]

I suspect that this might not go down too well, but I would personally recommend introducing a system whereby projects/scripts/plugins should be "certified" or "approved" to ensure that some minimum standards and some kind of compatibility can be achieved.

 

Thanks for the feedback. There is of course no solution for this situation without drawbacks but I will detail how some improvement were introduced.

 

In the present winbuilder edition, plugins are installed directly from our download portal here at the reboot site. This is a big difference because in the past the project administrator was required to include the scripts from other developers and keep them updated.

 

Now, other developers can make available their plugin directly on the download center. Get feedback, add updates and keep them running.

 

When a plugin gets outdated or broken for some reason, it is easy for any forum member with moderator permissions (currently the members on the .script developer group) to move the broken plugin for a forum section called "sandbox" that is not available to normal end-users looking for plugins to install. This way the task of managing the old plugins and keep them updated is shared by more people on the forum.

 

There are drawbacks to this approach:

1. When reboot.pro goes offline, there is no download center available
2. If some developer decides to do something nasty, can make a bad plugin available directly on the portal without supervision
3. Developers at other wb-focused sites will not like this approach, forces them to either use this site or do something else instead

 

On the other hand, keeping the official wb dowload center here on the forum is helping to concentrate user feedback and raise attention for developers to make changes on their own initiative. This might work better than certification since no project developer will change in bulk the plugins of other developers without talking to them first, making it more difficult to destroy a common API as seen some months ago from people in other sites unless a significant number of other developers agree that the proposed changes are indeed meaningful.

 

 

The scenario of a plugin supporting multiple Windows types should soon work in the following manner:

    void startup(){
        core.getLog().hooks.addAction("Adding WinPE x86 plugins..", thisFile, "x86Install");
        core.getLog().hooks.addAction("Adding WinPE x64 plugins..", thisFile, "x64Install");
        }
        
    void x86Install(){
        log.write(is.INFO, "FEATURE: Installing software abc");
        // do the specific x86 dependency check here
    }
    
    void x64Install(){
        log.write(is.INFO, "FEATURE: Installing software abc");
    }

In the old winbuilder, you would create a plugin knowing that it would run with a specific level of priority. On the next winbuilder the concept of levels was replaced with the concept of hooks.

 

Basically, the plugin tells winbuilder that when a specific message appears on the log then it should launch a specific code in the script.

 

Explaining the code from the snippet, the "startup()" method is a code group that will be run when winbuilder first starts and goes through each plugin on the downloads folder. In the startup() we are launching two hooks. The variable "thisFile" is just a pointer to the current plugin, much like %scriptfile% and the last parameter is the name of the method that you want to launch.

 

When the log outputs the message "Adding WinPE x86 plugins.." then the plugin launches the x86Install() method.

 

 

In essence, you can actually "hook" your plugin to any message that the builder outputs. It would be difficult to output messages that have variables inside them, such as "Hello Nuno Brito". To solve this, we use the same approach of C++ strings and put the variable parts of the message outside of the message, changing it something like log.write(is.INFO, "Hello %1", "Nuno Brito");

 

With this solution, you can write hooks to the message "Hello %1" or anything else you wish. It is even possible to reintroduce the concept of levels if someone really misses them. I like the fact that now plugins are no longer stuck to a single time running, they can be called several times during a build according to which phase needs something from them. One other advantage of this approach is that full translation of the text to other languages is now possible without the need for editing any plugin. All the text strings are stored on a single separated file, if the text does not exist on the translated version then it just uses the English one available.

 

 

In regards to preserve interoperability between wb projects, we tried:

- Default project (2005)

- Common API (2007)

- Script certification (2011)

- Single download center (2013)

 

Let's see how many years the most recent approach will last. From my side I think we finally reached the goal that was set up some years ago of providing a simple and fool-proof winbuilder. Right now any user just needs to type "AUTO" and has a WinPE available. We can even add a GUI with a single button to avoid the need of typing anything with the keyboard. However, I'm giving priority to ensure first that winbuilder is accessible to visually impaired users.

 

A lot of work. Slowly, but steady we move.

[misty]

Thanks to the instructions in steve6375 post (#3) I was able to successfully build a working Windows 7 based PE - first time. A remarkable achievement - for the developers - not me - although well done me too.

 

Well done to everyone involved.

 

I'm a tweaker by nature (and I don't mean the Breaking Bad meth junkie type of tweaker, thank you very much!) so I look forward to playing around with this in future.

 

@Nuno

Thanks for the response and explanation.

[Wonko the Sane]

In the present winbuilder edition, plugins are installed directly from our download portal here at the reboot site. This is a big difference because in the past the project administrator was required to include the scripts from other developers and keep them updated.

 

Now, other developers can make available their plugin directly on the download center. Get feedback, add updates and keep them running.

 

When a plugin gets outdated or broken for some reason, it is easy for any forum member with moderator permissions (currently the members on the .script developer group) to move the broken plugin for a forum section called "sandbox" that is not available to normal end-users looking for plugins to install. This way the task of managing the old plugins and keep them updated is shared by more people on the forum.

 

There are drawbacks to this approach:

1. When reboot.pro goes offline, there is no download center available
2. If some developer decides to do something nasty, can make a bad plugin available directly on the portal without supervision
3. Developers at other wb-focused sites will not like this approach, forces them to either use this site or do something else instead

 

On the other hand, keeping the official wb dowload center here on the forum is helping to concentrate user feedback and raise attention for developers to make changes on their own initiative. This might work better than certification since no project developer will change in bulk the plugins of other developers without talking to them first, making it more difficult to destroy a common API as seen some months ago from people in other sites unless a significant number of other developers agree that the proposed changes are indeed meaningful.

 

If I get this right, it is exactly like the App Store (or Windows Store) with only free NEW Winbuilder plugins, correct?

 

 

Wonko

[Brito]

Hi Wonko,

 

App store are recent things, we've already been making this kind of service available since 2005. It is actually inspired by the Debian way of installing software with apt-get. I've tried different approaches for making the sharing of plugins/scripts between end-users and developers as simple as possible, here is an example from 2007: http://reboot.pro/to...php-new-server/

 

This time, I've decided to use our site to concentrate both the downloads and feedback of end-users instead of writing a new platform from scratch just for this matter. This way, when a plugin goes broken then a feedback topic is always available and it is simpler to place it away from the available downloads through a web interface when needed.

 

By your comparison to the App store or Windows Store I get the feeling you want to point out a closed ecosystem type of distribution. For the moment this is true, I am only supporting our downloads portal here. If someone else wants a different server, they can install the same forum software that we use and change the URL to their site.

 

It is possible to write a replacement to the download component in winbuilder that is suited to other web platforms, I just won't dedicate my time coding this kind of implementation to cater some specific developers that would then keep bashing our work around here despite using it every day.

[Wonko the Sane]

By your comparison to the App store or Windows Store I get the feeling you want to point out a closed ecosystem type of distribution. For the moment this is true, I am only supporting our downloads portal here. If someone else wants a different server, they can install the same forum software that we use and change the URL to their site.

Yes, and no.
Meaning that it seems to me, leaving technicalities apart, that the way the thingy works (for the final user) is essentially the same (though there are no pay-for apps and no 30% Apple or *whatever* MS fees ), there is nothing inherently "bad" in the approach, it is simply something that greatly limits choices.
I am pretty sure that a large number of members will actually like this approach , the fact that I personally find it one among the most foolish possible approaches, not just the "script store", the whole idea (again) of providing something that is scarcely documented (if documented at all) and that is incompatible (seemingly) with the past seems to me like a show stopper for a developer.

I will modestly (again) try to re-submit the idea that the first "next" priority should be IMHO that of *somehow* providing a "translator" even if "rough", see:
 http://reboot.pro/to...ilder/?p=176898

The whole point about a "controlled" (or "closed") redistribution system is that things are actually "controlled", if they are not (the only "limit", if I get this right, is to belong to the "developer" group) it makes little sense.

If you prefer, the reason why the current "AUTO" project works is IMHO because Peter has done a very good job in writing it's scripts/whatever (besides the good work on the "engine"), though, in any case, it is a "very vertical" kind of thingy, but as soon as the thingy will get some "momentum" it is not so hard to forecast that half-@§§ed scripts (or whatever) will be submitted, creating exactly the same (or very similar) compatibility issues there were in the past.

I personally believe more in "educating" the willing good guys (into writing "better" scripts and either maintaining them properly or making easier for other good willing guys to maintain them ) than in "forcing them" into a "structure" of any kind that not necessarily (IMHO) guarantees any particular advantage.

All the Common API fuzz about not being actually "common" at all is IMHO mainly bull§hit, anyone familiar with any programming of any kind on Windows has already met the "DLL hell" and one way or the other - though obviously a nuisance - it hasn't stopped the world from turning around.

 

It is possible to write a replacement to the download component in winbuilder that is suited to other web platforms, I just won't dedicate my time coding this kind of implementation to cater some specific developers that would then keep bashing our work around here despite using it every day.

Sure , you should protect your creature from the bashing guys , I can understand that alright.
But the whole point is IMHO that - set apart - (possibly) the increased speed at building time of the NEW Winbuilder, the number of "advantages" when compared to the OLD Winbuilder are not-so-evident.


Wonko

[Brito]

But the whole point is IMHO that - set apart - (possibly) the increased speed at building time of the NEW Winbuilder, the number of "advantages" when compared to the OLD Winbuilder are not-so-evident.

 

Good.
 

All the Common API fuzz about not being actually "common" at all is IMHO mainly bull§hit, anyone familiar with any programming of any kind on Windows has already met the "DLL hell" and one way or the other - though obviously a nuisance - it hasn't stopped the world from turning around.

 

You're entitled to your opinion. To me this was a short-sighted act of cruelty. There are people to blame on both sides of the fence, the problem is that end-users are the ones suffering from these conflicts. I can't change people or ask them to be nice with each other, what I can do is write software to reduce the impact of such situations recurring in he future.

 

The advantage of winbuilder is guaranteeing a simple and fast build without fuss for the end-user. Mission accomplished.

[Wonko the Sane]

The advantage of winbuilder is guaranteeing a simple and fast build without fuss for the end-user. Mission accomplished.

No.

But if you are happy believing that, it's perfectly OK.

JFYI, *ANY* "single" or "vertical" project (or build) can be made with *any* tool, including the half-@§§ed batch language I often use, the OLD Winbuilder, Visual Basic, Auto-It or *whatever*, and this can be made "simple" (though not necessarily "fast" or "as fast as the NEW Winbuilder").

So, it is fast , but it is ONLY as simple as the "AUTO" project is.

The end users are suffering from  this choice, rest assured, in the sense that they have no (or very little) choices right now.

 

The short-sightedness is IMHO in throwing away the whole past ("old" syntax, .scripts, syntax, libraries and developer experiences) with such a wide gap and without providing a "bridge" (or even the "instruction manual" for the "new" thingy).

 

Of course time will tell, but consider how the "old paradigm" worked (in 6 points):

1. I am a good willing kid (no offence intended ).
2. I have a few ideas that I implemented half-@§§edly (no offence intended ) using the only tool I can put together a few lines of code together with (Delphi).
3. Let's all together debug and find ideas on how to better this new engine and scripts for it.
4. Let's all together write new syntaxes (if needed) and write .scripts for making use of this engine.
5. Let's all together find new, strange ways to solve problems through this engine and .scripts running from it, no matter how crazy might your idea be, we will talk about it and consider it if possible.
6. Let's start having fun together.

as compared to the current one (as well 6 points, for simplicity):

1. I am a competent programmer.
2. I have partnered with another very competent programmer (who is not reknown for his flexibility in accepting other people's ideas and whose clarity - outside the strictly programming topic - is debatable).
3. Together we have put together an exceptionally good engine which is NOT subject to any change because we have decided that it is perfect (besides fast), any needed change will be made undocumented or mis-documented.
4. We do not provide any kind of documentation, nor support about how to write scripts for this new engine, and we won't change anything in it (see above, it is already perfect) unless we ourself decide to change something, rest assured that we will listen to your bug reports or feature requests and then arbitrarily decide to do whatever crosses our mind, disregarding each and every idea submitted if not 100% identical to one we might have had ourselves.
5. Any script has in any case to be provided exclusively through our site.
6. If you want to write a script for this engine, that is your problem, just look how the current scripts are written and do the same. 

They are two very different models, one - which BTW had some non-trifling success - and that contains a lot of "let's" and "fun", and another one which success will be seen in the future, but that right now contains a lot of distinction between "we" and "you" and where very little funs seems to be involved.

Wonko

[Brito]

The short-sightedness is IMHO in throwing away the whole past ("old" syntax, .scripts, syntax, libraries and developer experiences) with such a wide gap and without providing a "bridge" (or even the "instruction manual" for the "new" thingy).

 

It is not difficult to type "auto" on the screen and press enter to get a boot disk working. Right now I'm worried that the plugin support is still not well stabilized, don't want to document the current approach when so many changes are still expected.

 

as compared to the current one (as well 6 points, for simplicity):

 

 

I'm bitter because I need to answer lengthy and multiple criticism opinions whenever a new version of winbuilder comes up. This is demotivating but needs to be done or otherwise this kind of cynicism tears down any effort to bring an improvement. God forbid if any changes later need to be applied. There is scarce room for users to give feedback and for us to apply constructive improvements.

 

If you want to see me happy, try winbuilder and then let me know how it worked for you.

[Wonko the Sane]

If you want to see me happy, try winbuilder and then let me know how it worked for you.

Still 6 points:

1. I did try it.
2. It is fastish .
3. I don't care about the language it is written in. (that's a technicality that is your business, security concerns are m00t as there is no increased risks IMHO when compared to the OLD Winbuilder, which however I always rated - without ever hiding my opinion on it - an extremely insecure approach, coupled with the common advice often provided of "try running it after having switched off the antivirus" )
4. I don't care about the lack of a GUI. (actually since I hated - since the dawn of time - the open-folder/drop-down kind of interface the OLD Winbuilder sported among a zillion other programs and traditionally like CLI, I do prefer it, but this is only "appearance") 
5. I noticed NO improvement of any kind (exception made for speed) over the OLD Winbuilder.
6. I don't like the total absence of anything else but the AUTO project, which I understand is a temporary limitation due to the new release, the point is just if and when this situation is likely to change (if it will change at all).

 

If you hadn't noticed, my previous criticism/observations were not at all towards the app in itself (which is innocent and OK, AFAICU, though I will repeat how it is a script interpreter, no brain surgery or rocket science involved), only on the developing model, particularly when it comes to involve in it script developers and "common" members wishing to become developers.

 

 

Wonko

[Brito]

Thanks for the feedback. Made me happy.

 

I don't like the total absence of anything else but the AUTO project, which I understand is a temporary limitation due to the new release, the point is just if and when this situation is likely to change (if it will change at all).

 

If you're feeling adventurous, type "list" to see the other commands available.

 

To know the syntax for each of the listed commands, just type the name of the command followed by an "?"

 

For example, "install list" will bring up a list of downloads available for expansion of the boot disk. To modify the settings, type "config win7pe".

 

[farzad_Oscar]

13:05:38 [COMMAND] config win7pe

13:05:38 [ERROR] There exist no settings available for this plugin yet, sorry!

 > 

 

 

why ? what should i do ? 

 

 i want to add AVIRA in my winpe poject . some one tell me how with detail PLZ

 

Thx Every one

[Wonko the Sane]

For example, "install list" will bring up a list of downloads available for expansion of the boot disk. To modify the settings, type "config win7pe".

 

 

 

 

13:05:38 [COMMAND] config win7pe

13:05:38 [ERROR] There exist no settings available for this plugin yet, sorry!

 > 

 

 

The advantage of winbuilder is guaranteeing a simple and fast build without fuss for the end-user. Mission accomplished.

 

 

Simple and without fuss .

 

@farzad_Oscar

You can use, like everyone else on this site, "normal" fonts and colour and reserve huge size, bolding and non-black text colour to only highlight a single word or sentence, the way you posted it seems like you are SHOUTING (at the good NEW Winbuilder developers, which may be appropriate speciifcally , but still not particularly nice towards them ).

 

Wonko

[Brito]

Hi Farzad.

 

Type "auto". Then you can make changes on the boot disk.

 

There is no support for Avira at this moment, please open a request at this forum section: http://reboot.pro/forum/74-requests/ or use one of the older winbuilder projects that already comes with support for Avira.

[farzad_Oscar]

i did

 

but it want to download somting 

i want use this program in offline mode

 

why that command dos not work ? config win7pe 

 

and i want add avira to my project

[florin91]

Maybe using source ( and choose the W7 source folder) and build. But if you want to use it offline, I think you might still need the files from this site (manually downloading?) and extracting them in the correct location and creating xml files with settings.

This program is only to be used online only with that install command?

The good thing is that old Winbuilder (same names?) is already there ...

[Brito]

but it want to download somting 

i want use this program in offline mode

 

why that command dos not work ? config win7pe

 

Winbuilder needs to download two things from the Internet:

• A Windows ISO from where the files to build the boot disk are copied
• The most recent version of Win7PE

The command that you are typing doesn't work because you need a Windows source and a WinPE project to be installed as well. Neither of these are included by default on the download package.

 

 

If you want to do things "offline":

1. Download the ISO of Windows 7 SP1 from http://msft.digitalr...n/X17-59183.iso
2. The download is around 2.5Gb, when finished it must have an exact size of 2564476928 bytes
3. Extract the ISO to an empty folder, such as "c:\source\win7sp1" using a tool such as 7zip
4. Verify that a huge number of files was extracted (more than 100)
5. Download the most recent Win7PE project from here: http://reboot.pro/fi...ile/300-win7pe/
6. Extract all files to the download folder of winbuilder. For example, c:\winbuilder\downloads
7. Run winbuilder.exe
8. Type "source" and select the folder where your Windows files from step 3 were extracted
9. Type "set project Win7pe" to define Win7PE as the default project to build
10. Type "build" to start the construction of the boot disk
11. Post the error here on the forum
12. Apply changes as specifically mentioned by the folks here
13. Jump back to step 10 when the next error appears
14. Done

In alternative, type "auto" and let winbuilder take care of all these things.

 

As for Avira, please read my previous post. Thanks.

[homes32]

there is unlikely going to be a plugin available for complicated scripts like avira until proper documentation is made available to the .script developers on how to interface with the new winbuilder engine.