Hello dear guest!

Boot Land is a community driven pc software site established since 2006 and focused on recovery/backup boot disks, research of Microsoft Windows 2000/XP/2003/Vista/7 install/deployment/lease/antivirus/antispam tools, customizing Microsoft Windows PE administration systems and even learning how to recover computer data from disaster situations!

How about joining our boot disk community? So do it. Life's short!

  - You get free access to our newsletter with all the interesting buzz about boot disks
  - We share publicity revenue with everyone who wishes to participate at the forums
  - Publicity is never, never, never displayed to members (along with many other cool things)
http://boot-land.net/register


144 Pages V   1 2 3 > » 

Pinned: [Package] PEFactory
Galapo
Posted on: Today, 12:38 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


%TargetWOW64% is most needed for CAPI. It is used to determine if a program is compatible with PE architecture and/or existance of wow64.

Because %TargetWOW64% is a variable in current existance, no need to create %x8664% variable which does exactly the same thing.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #102495 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Today, 12:17 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (psc @ Jun 16 2010, 10:06 PM) *
Thanks, Galapo. This again proofs that nativeEX_??? projects are the only projects which claim and perform "Take everything from the source CD only".
No cross-links, no additional defines etc.

Yes, that's exactly the point: wow64 can be taken from source CD and built into x64 PE. Hence the need for the variable to determine if wow64 exists so that CAPI require_file calls etc. for a 32-bit app will extract the wow64 files and not 64-bit files.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #102490 · Replies: 39 · Views: 1,303

WinBuilder 081 RC1 published
Galapo
Posted on: Yesterday, 11:22 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


Hi Peter,

Just wondering if you have the answer to the question asked above in and in a couple of other places:

QUOTE
I see no gain in changing the behaviour of %ISOFile% to a constant rather than a variable. What is the reasoning for this?


Thanks,
Galapo.
  Forum: News · Post Preview: #102450 · Replies: 33 · Views: 2,661

Pinned: [Package] PEFactory
Galapo
Posted on: Yesterday, 09:23 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11



Hi Peter,

I made a mistake. It should have been:

CODE
[nativeEx_barebone]
If,Not,ExistVar,%TargetWOW64%,Set,%TargetWOW64%,%SourceArch%,PERMANENT
...


That's because %TargetWOW64% can be set by another script, ie when wow64 exists under a 64-bit PE.

%TargetWOW64% is used in VistaPEcapi, Leopard, Win7PE, Win7PESE, Win7Rescue, LiveXP. I know of one exception: nativeEx. I think it is better if you use an already existing used thoughout other projects, rather than forcing the use of a new nativeEx variable that is essentially duplicating function.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #102443 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Yesterday, 11:27 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (sbaeder @ Jun 13 2010, 04:53 AM) *
OR is it to also make a "multi-boot" image, where we can easily add in other things...


Currently, that's the easily the case with the DefineBootSector script of LiveXP and other similar scripts of a couple other projects. PEFactory hasn't implemented support as far as I can tell for the current existing dynamic generation of menu.lst of other projects. Peter might have that in the works.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #102408 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Yesterday, 11:21 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (psc @ Jun 11 2010, 07:16 AM) *
Thell the package some fundamental values:
(current "state of art":)
CODE
Run,%BootManagerScript%,%ProjectTitle%

[nativeEx_barebone]
Set,%x8664%,%SourceArch%,PERMANENT
Set,%ProjectType%,1,PERMANENT
...


Hi Peter,

To me, there seems some redundancy here. Your new variable %x8664% seems to do the same thing as existing %TargetWOW64%. Currently, %TargetWOW64% is used by other projects except nativeEx, so no need to introduce another variable. Just change to:

CODE
[nativeEx_barebone]
Set,%TargetWOW64%,%SourceArch%,PERMANENT
...


Also, new variable %ProjectType% seems to do the same thing as existing %API_TYPE%. Currently, %API_TYPE% is either set by api itself or, better, if project sets it at script.project as is mostly the case. So no need again to introduce another variable, as %API_TYPE% has been existing on api for a long time now. Just change to:

CODE
[nativeEx_barebone]
Set,%API_TYPE%,1,PERMANENT
...


Regards,
Galapo.
  Forum: NativeEx · Post Preview: #102407 · Replies: 39 · Views: 1,303

File-system redirection
Galapo
Posted on: Jun 13 2010, 11:52 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (Lancelot @ Jun 14 2010, 08:52 AM) *
Sure it is thumbup.gif And be sure after stable release your script will be in livexp distribution when you flag stable cheers.gif (I guess Galapo would agree too)

Yes, I definitely agree! This is very exciting development -- imagine being able to have a replacement for fbwf.

Regards,
Galapo.
  Forum: Project forge · Post Preview: #102312 · Replies: 20 · Views: 1,199

Pinned: [Package] PEFactory
Galapo
Posted on: Jun 11 2010, 10:44 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


Peter, this crucial post still remains unanswered: http://www.boot-land.net/forums/index.php?...st&p=100516

As previously stated, this should be the practice:
QUOTE (Galapo @ May 19 2010, 10:11 AM) *
In my opinion, we should be able to drop the new WB into our projects and have them work. The only exception to this would be in the case of an actual script bug, or if there is agreement among WB development and project maintainers that a crucial syntax change necessitates not supporting backwards compatibility.

Now, I know you disagree. But the reality is that not doing this just gets people offside. I hope this isn't your underlying intention -- I really do hope that you desire a WB that works with other projects and actually supports other developers. At the moment, I don't feel that's the case.

Thanks,
Galapo.
  Forum: NativeEx · Post Preview: #102117 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Jun 10 2010, 09:35 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (psc @ Jun 11 2010, 07:16 AM) *
The project author only has to do one thing: Thell the package some fundamental values:

Given our discussion above, I fail to see how this could possibly be the "one thing" that a project maintainer has to do. For LiveXP, I've already explained how PEFactory in its current implementation is fundamentally incompatible. As explained, that's not necessarily a problem with LiveXP, just that PEFactory can't cover all the options without additional development on PEFactory.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #102090 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Jun 5 2010, 02:23 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (MedEvil @ Jun 6 2010, 12:19 AM) *
I sure hope PEFactory will not turn into a LiveXP kinda script, where millions of options are thrown at the user.

Well, you could stop complaining and do some script updating yourself.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #101679 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Jun 5 2010, 01:28 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (psc @ Jun 5 2010, 11:20 PM) *
The PEFactory is intended to be simple and fullfill 9x% of all cases without any "expert knowledge" of the user.

Ok, I was just providing this feedback because in the link you provided you've written: "PEFactory package is a solution to have ONE final PE build / test for ALL projects." I assumed "all" meant all, so was providing feedback from a LiveXP perspective. Currently I'm not sure PEFactory will work as it doesn't provide compatibility with currently implemented grub4dos options.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #101672 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Jun 5 2010, 12:42 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


I think it gives an issue if someone wants to use a particular version. For example, I prefer a chenall build as it provides progress indication when ram-booting.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #101667 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Jun 5 2010, 11:42 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


Ok, thanks for the info. It might work as-is.

What about the file grldr? Would Grub4DosStandard.script overwrite one already supplied earlier in build?

Thanks,
Galapo.
  Forum: NativeEx · Post Preview: #101659 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Jun 5 2010, 10:38 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (psc @ Jun 5 2010, 08:30 PM) *
I'm sure that the functionality of DefineBootsector.Script is fully or 99% contained in the PEFactory package.

Current functionality is:

MenuAdd_GRUB,grub4dos_entry,Prepend|Append|RemoveDefault

Supplied menu.lst entry can be prepended or appended to menu.lst. Alternatively, the default option can be overwritten by the one supplied if that is desirable.

Regards,
Galapo.
  Forum: NativeEx · Post Preview: #101648 · Replies: 39 · Views: 1,303

Pinned: [Package] PEFactory
Galapo
Posted on: Jun 4 2010, 09:13 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (psc @ Jun 5 2010, 12:21 AM) *
Maybe there are opinions, suggestions etc. before a publish of the package

Hi Peter,

Thanks for this. I do have two suggestions. First, it'd be great if PEFactory was compatible with WimPack. Second, it'd be great if it were compatible with RegFactory.

Also, since we can't test yet, I'm not sure if this suggestion has already been implemented. But it'd be great if the grub4dos option supported the current mechanism of adding and replacing items like with the DefineBootsector script.

Thanks,
Galapo.
  Forum: NativeEx · Post Preview: #101587 · Replies: 39 · Views: 1,303

Reinstall / Repair Windows automatically without formatting the disk.
Galapo
Posted on: May 31 2010, 08:04 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


See my post here: http://www.boot-land.net/forums/index.php?...amp;#entry27510

Regards,
Galapo.
  Forum: Project forge · Post Preview: #101263 · Replies: 16 · Views: 3,714

Are you getting email notifications?
Galapo
Posted on: May 26 2010, 08:24 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


I'm getting notifications.

Regards,
Galapo.
  Forum: Site feedback · Post Preview: #100976 · Replies: 13 · Views: 505

WinBuilder Script Editor Suggestions
Galapo
Posted on: May 25 2010, 09:54 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


I add my vote for the implementation of #1, #2, and #6. #2 and #6 would be especially helpful at times.

Regards,
Galapo.
  Forum: Support · Post Preview: #100931 · Replies: 21 · Views: 938

can not creat wimboot
Galapo
Posted on: May 24 2010, 12:46 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


WBVerify checks what scripts and selections you have made for needed dependencies etc.

Since you're using WimPack and WimBoot, you need to change the ProgramFilesPE script setting from '%SystemDrive%' to '%Settings Drive%'.

Since you've got the WimBoot script selected, you need to supply some MS files in order to make it work (these cannot be distributed with the project since they are non-distributable files). What files are needed etc. are listed on the script's interface.

Regards,
Galapo.
  Forum: LiveXP · Post Preview: #100815 · Replies: 10 · Views: 740

WinBuilder 081 RC1 published
Galapo
Posted on: May 21 2010, 09:07 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (Wonko the Sane @ May 22 2010, 06:42 AM) *
.... possibly without creating a worse illness and without having ALL patients pissed off and yelling at you...

Exactly! It seems WB development goes out of their way to create this unfortunate situation where project developers get ticked off.

Of course, up until now we've played the game of (sometimes quite extensive) updating projects when a new WB stable is released due to lack of backwards-compatibility with WB. But I think now after 3 years we're all a bit tired of this.

The fact is that we currently have a RC which is not known to work with any current projects.

Regards,
Galapo.
  Forum: News · Post Preview: #100698 · Replies: 33 · Views: 2,661

WinBuilder 081 RC1 published
Galapo
Posted on: May 21 2010, 08:17 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (psc @ May 21 2010, 11:14 PM) *
Because nativeEx does not exist any more, this question is obsolete.

Peter, seriously, the point remains the same because it arose at a certain point in time when nativeEx was available. The point is that you've changed %ISOFile% from a variable to a constant and have not provided your reasons for doing so.

Currently, we have a RC which does not work with any projects (%ISOFile% is just the relevant example, there are other issues as well). Why do we have to have this situation?

Thanks,
Galapo.
  Forum: News · Post Preview: #100693 · Replies: 33 · Views: 2,661

Galapo
Posted on: May 20 2010, 11:17 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


Under a PE there can indeed be duplicate files depending upon apps etc. I'll let you discover this for yourself.

Regarding using a new compression algorithm in WIM images, one important issue you'll need to confront is getting such an image mounted to the file system as current WIM images do. Sure, compression with 7z will be smaller, but will there be a performance hit with read-write access vis-a-vis the current algorithm? With 7z I strongly suspect there would be as its designed for compression, not as a potential container for a booting PE.

Regards,
Galapo.
  Forum: NaughtyPE · Post Preview: #100650 · Replies: 11 · Views: 718

Galapo
Posted on: May 20 2010, 09:54 PM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


I just did a test on the outputted target folder of a LiveXP build. Folder was 168MB and compressed as the following:

ZIP: 87MB
WIM: 84MB
RAR: 77MB
7z: 65MB

That's about what I would have expected. WIM compresses better than ZIP. WIM will come down considerably if there's duplicate files.

Regards,
Galapo.
  Forum: NaughtyPE · Post Preview: #100645 · Replies: 11 · Views: 718

Galapo
Posted on: May 20 2010, 10:39 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


You haven't mentioned anything about a script, so I don't know what you're meaning. But details on WIM here: http://msdn.microsoft.com/en-us/library/dd851934.aspx. There's either 'NONE', 'XPRESS', or 'LZX'.

Regards,
Galapo.
  Forum: NaughtyPE · Post Preview: #100616 · Replies: 11 · Views: 718

nativeEx news
Galapo
Posted on: May 20 2010, 05:56 AM


Platinum Member
******

Group: .script developer
Posts: 3,657
Joined: 16-July 06
Member No.: 11


QUOTE (psc @ May 20 2010, 03:43 AM) *
The issue here is that the 1% (or 2% / 3% - see the other posts about %ISOFile% -) are trying to declare a new version as bad, because it demands 2 minutes of adapting some existing scripts.
And of course, the adapted scripts will work with older WB versions!

Peter, %ISOFile% has just been the example. There's other areas where the RC is not backwards-compatible as well. I used %ISOFile% as a focused example showing that again the move to a new stable version is again bringing the same story of lack of backwards compatibility. Not because of new features, but because of changes to basic rules of syntax and what can and cannot be done. I'm getting the feeling from the example of %ISOFile% that nothing about WB development is going to change anytime soon. There's no plan in place to avoid issues such as this arising again -- projects developers seem to have to just live with the fact that WB stables are just not meant to be backwards-compatible. Something such as %ISOFile% can be changed over night, breaking compatibility, without being consulted about this.

Given this development structure, it really shouldn't surprise you that people will be upset about this. People get frustrated when time and again it is found that the new WB cannot be used as-is with a project compatible with the prior WB release.

Regards,
Galapo.

  Forum: NativeEx · Post Preview: #100600 · Replies: 9 · Views: 784

144 Pages V   1 2 3 > » 

New Posts  New Replies
No New Posts  No New Replies
Hot topic  Hot Topic (New)
No new  Hot Topic (No New)
Poll  Poll (New)
No new votes  Poll (No New)
Closed  Locked Topic
Moved  Moved Topic