Jump to content











Photo
- - - - -

Parsing XML Files


  • Please log in to reply
24 replies to this topic

#1 larioteo

larioteo

    Member

  • Members
  • 79 posts
  •  
    European Union

Posted 19 May 2011 - 06:21 AM

Hello there,

as Nuno writed i am starting here a new Topic about a new useful feature for our winbuilder.

Parsing XML Files

as everyone knows that since Windows Vista microsoft is extremly using xml files, it would be
a nice feature to read content from them.

That is it.

What you others do think about it.

#2 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 19 May 2011 - 11:38 AM

Nothing to do with vista. XML app config files appeared with .NET applications as a replacement to using the registry. So far have not yet seen a need to update them in any winbuilder script. If you need to there is always the MS COM DOM usable from vbs and other scripting languages.

#3 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10547 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 19 May 2011 - 01:50 PM

I recognize the importance of XML files, but can we have some practical examples where it is applied?

I say this because reading XML files is a feature that can also be provided by an API command in projects that require this type of functionality.

:)

#4 ChrisR

ChrisR

    Silver Member

  • .script developer
  • 784 posts
  •  
    France

Posted 19 May 2011 - 02:34 PM

The same thing is done in Win7Pe SE with a small program AutoIt "WimInfo", written by JFX which writes wim information in an ini file then exploited by WB.
With WimInfo Usage :
- Path To Imagex.exe or 7z.exe (>= 4.00)
- Path To Wim file
- Path To Ini file

I do not see an important need for this function directly in WB, avoid the complexity, Simple and safe.

#5 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 19 May 2011 - 03:20 PM

The same thing is done in Win7Pe SE with a small program AutoIt "WimInfo", written by JFX which writes wim information in an ini file then exploited by WB.
I do not see an important need for this function directly in WB, avoid the complexity, Simple and safe.

And also in Win7RescuePE, nativeEx_multiPE and several projects created by pecd.net, with a small program "WinInfo" pscEx created which writes WIM information directly into the GUI.

I also do not see high necessarity for WB to extract info from XML files.

Peter

#6 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 19 May 2011 - 03:41 PM

I tend to agree with above comments. Yes, getting information from a WIM file is one place that needed a solution, and as pointed out, there are many ways to skin that cat (sorry cat lovers)...

I think that as pointed out, this is a worthy "goal" for the future, but for now, the direct manipulation of the XML might be better left up to external processing.

My question (for folks more knowledgeable) and related to this (hence not new topic yet) is this...Is there a way to run an external command (like the ShellExecute commands) that can load it's output (return parameter?) directly into a variable? This would simplify the process we use today where we run an external command that creates an INI formatted file that we then "read" to get the contents into a variable...

Maybe that is a way to provide this sort of thing - although, I do see that as something easy enough to build into a simple enough API routine...

Scott

#7 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 19 May 2011 - 03:54 PM

My question (for folks more knowledgeable) and related to this (hence not new topic yet) is this...Is there a way to run an external command (like the ShellExecute comma


#8 sbaeder

sbaeder

    Gold Member

  • .script developer
  • 1338 posts
  • Location:usa - massachusettes
  •  
    United States

Posted 19 May 2011 - 07:36 PM

Currently we only have the %ExitCode% which really gets the numerical exit value of an external app.
Strings cannot (yet?) be passed into a %variable%. Since a while I use registry entries rather than writing to an ini like file. IMO that is faster.

When there is only one string given back, for my projects, it allways is in HKLM\Software\easyPE\Result.

Peter

Thanks - Yes, a registry write should be faster, since a file already exists, etc. Maybe not a lot, but again, depends on how often it is used. Not sure that there is a simple way for an external application in a separate process to return a string...Maybe a future method would allow calling an external DLL entry point??? (just thinking out loud, since for now, I think we have all we can "handle" :)

Cheers
:cheers:

#9 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 19 May 2011 - 07:47 PM

Maybe a future method would allow calling an external DLL entry point??? (just thinking out loud, since for now, I think we have all we can "handle" :)

I already thought on that. And as far I remember, discussed with "The Boss" (Maybe that the idea even came from Nuno). But by any reasons, I did not follow the idea ...

Peter

#10 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10547 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 19 May 2011 - 08:45 PM

Is there a way to run an external command (like the ShellExecute commands) that can load it's output (return parameter?) directly into a variable? This would simplify the process we use today where we run an external command that creates an INI formatted file that we then "read" to get the contents into a variable...

Hello,

This problem has been thought before and perhaps it is time to share these thoughts with the community.


Some context:

WinBuilder strives to be agnostic from the Windows structure as much as humanly possible. This is one of the reasons why we don't adopt .NET nor adopt DLL's for external libraries, nor adopt the Registry for storing data.

An example of depending too much on Windows is Bart's PE builder that is nowadays unable of using newer platforms and we don't want to follow the same path. I also want to avoid adding more dependencies on 32/64/128 binaries/OS's.


The problem:

We want to share data between external processes and winbuilder.exe - this data can take the form of variables or any other format in the future.

Currently, we use INI files, the registry and other approaches. Some problems arise such as data synchronization and access to the inner engine for running specific tasks.

We also need to modernize WinBuilder. Delphi is moving onto extinction and Windows in 32 bits is being phased out. We are not taking advantage of the recent improvements in programming tools (JUnit, FindBugs, project profilers, modern IDE's, etc).


The proposed solution:

The next WinBuilder version will provide web services.

For example, we can use this code to get the value of a variable from the LiveXP project:

http://localhost:10101/project/livexp?action=getvariable&key=projectdir&value=blabla


To write the value of a variable (even if it does not exist):

http://localhost:10101/project/livexp?action=setvariable&key=projectdir&value=blabla



This allows expansion and full integration of the winbuilder engine with external tools. For example, other programs can start a winbuilder project, get the last generated log or configure settings inside a given project. This way people can even build wrappers that only use the engine and implement their own interface if desired.


Under the proposed solution, winbuilder scrips are able of calling through webget any other service also running at localhost and the called service can interact back with winbuilder in asynchronous manner.



There also disadvantages (for example: the need of opening a local port) and some risks (malicious tampering of variables or projects) but we have good people to help us make this service robust and safe across future versions.



Last but not least, there also plans for moving the WinBuilder engine from Delphi/Windows to the OS agnostic Java platform. It is of our best interest to only adopt new functionalities not tied to Windows from here forward while transitioning the current features to a platform agnostic state that can continue running in future years without worries.

We can already handle registry hives natively, only missing to achieve the same result for WIM (but we are already working on this goal as well).

One note of advice, these are plans for the upcoming years.



In September 2011 (or sooner), a new platform using this concept of web services and asynchrony will be made available. The next version of Winbuilder around December 2011 will feature basic integration with this platform. Slowly we'll begin the transition to Java to ensure that past works remain functional.


Perhaps now more people also understand why I am so worried about seeing a really well structured API, it eases the porting of apps scripts to other platforms and projects that are not available today, instead of forcing everyone to rewrite them later.

---------

Your feedback is welcome.

#11 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 19 May 2011 - 09:47 PM

Oh my god, Wb in Java? You know why it is called Java? Because one can fly to Java, grown and roast coffee beans to have a delicious cup of coffee, then fly back and arrive just in time, to see the program finish it's job. :cheers:

Trust me, back in the early years of this millenium, when "Java" was such a cool word, as "cloud" is today, our marketing department had the "brilliant idea", to redo all programs in Java, to increease sales.
With dollar signs in their eyes, management agreed and we had to implement the $%&#.
Guess what, every single one of our customers wanted first really the new Java version. Until they got it, then they wanted the C++ version again. :happy_dance:

Nuno, if you really won't to go independant, deliver WB with a feee (preferable own) LiveOS.


:cheers:

#12 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10547 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 19 May 2011 - 10:05 PM

Trust me, back in the early years of this millenium, when "Java" was such a cool word, as "cloud" is today, our marketing department had the "brilliant idea", to redo all programs in Java, to increease sales.

And because your company decided a decade ago to use a new technology because of a buzz word and failed, it means that for our specific case in the current days still holds true? :cheers:

Java has kept on evolving and improving. It will continue to do so in the future. What I see right now is a dead Delphi Pascal compiler that restricts access to better work conditions for everyone involved and the situation won't get better. If you are a fan of C++, that is fine. But I sincerely loath the need to recompile binaries for multiple platforms. A compiled binary in Java will continue to work over the next decades.

My friend, don't consider that this decision is based on marketing. I always look at the future times and prepare myself accordingly. This means a progressive move onto platform independence over the next years and Java provides a solid foundation for the next works.


Nuno, if you really won't to go independant, deliver WB with a feee (preferable own) LiveOS.

I see you like the all or nothing approach. I prefer to avoid extremes and tend to adopt a progressive approach.

Over the next years we should slowly move to a state where Winbuilder is capable of building hives, building WIM's and therefore create boot disks without running Windows underneath. This ensures that we can continue to build old projects even if Windows NT 9 no longer comes with a registry structure.

#13 larioteo

larioteo

    Member

  • Members
  • 79 posts
  •  
    European Union

Posted 19 May 2011 - 10:23 PM

If i can ask something, we are building Windows PE Environments, right? On a Windows machine, but why should the winbuilder be able to ran on linux or other platformws? Linux as its own has hundrets of liveos, ready to download, optimized, perfect, and so on.

Java, pff, what version, will it than be as seen from other software that we have to install 10 Java versions to can run seperate builders?

But i wont say java is the wrong way, c# i think would be the better and faster way, as easyest way, it is one of the easyest languages, and have also a framework that runs under linux, only to remember, we using java in the company and a slower software i have never seen, and this software is only collecting informations and storing them in a oracle database, nothing more, but terrible slow.

But a c# Tool is also slower than a native application, i wont only to say that a framework solution could be the wrong way, i am also a young developer, which must decide which language is the best one, and i must say D will be the next big thing, based on C/C++ which nearly everybody even can handle it, and making everything easy as java.

Excuse me if someone understood me wrong, my english is terrible i know. it is only a big question, when building on windows, why not to use windows framework? some functions would be realy nice for the builder, there are so many things build in, i should end here my statement/question

#14 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 19 May 2011 - 10:35 PM

My point, Nuno, was that Java is very, very slow, way more than Delphi. Given the time that the building of a project takes these days, i would really hate a drastic further slow down of the engine.

:cheers:

#15 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10547 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 19 May 2011 - 10:48 PM

If i can ask something, we are building Windows PE Environments, right? On a Windows machine, but why should the winbuilder be able to ran on linux or other platformws? Linux as its own has hundrets of liveos, ready to download, optimized, perfect, and so on.

Above all, it is a good exercise to keep us in fit conditions to survive on our own.

Excuse me if someone understood me wrong, my english is terrible i know. it is only a big question, when building on windows, why not to use windows framework? some functions would be realy nice for the builder, there are so many things build in, i should end here my statement/question

We want to keep on playing with Windows but Windows doesn't play so nicely with us sometimes.

It is getting harder to work with the registry, getting harder to work in new formats (WIM), getting harder to manage binaries (32 vs 64 bits), harder to run programs (Administrator/UAC permissions).

And this will not get easier. There are two ways of playing: defensive or offensive. I say that reboot.pro is a community of fighters and we're able of fighting back and implement our own way of creating boot disks without being so disturbed by changes on the underlying structure! :cheers:


My point, Nuno, was that Java is very, very slow, way more than Delphi. Given the time that the building of a project takes these days, i would really hate a drastic further slow down of the engine.

Wrong point. You are still thinking on a Java from 10 years ago.

With Java I am now computing more than 12 million commands under 60 seconds on a normal laptop.

Guess what, Java already comes with builtin load balancing across all available processors by default. Try doing the same in Delphi. :happy_dance:

It is not possible to quantify the effort put by SUN and now Oracle to have such an efficient compiler but the results are here for everyone to enjoy and the platform is free.

I've spent 12 years loving Delphi and since 2 years ago that I've been happily coding in Java. I'm also adverse to changes and all of this process is slow and cautious.


For some reason I have the impression that you believe that tomorrow we will already be using Java across all of Winbuilder. This is a gradual process and if the indicators show that it is really a bad decision, then we will just keep evaluating other options available to see which ones we should keep or drop.

As I've said, this is not an all or nothing attitude.

:cheers:

#16 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15014 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 19 May 2011 - 11:36 PM

Oh my god, Wb in Java? You know why it is called Java? Because one can fly to Java, grown and roast coffee beans to have a delicious cup of coffee, then fly back and arrive just in time, to see the program finish it's job. ;)


My point, Nuno, was that Java is very, very slow, way more than Delphi. Given the time that the building of a project takes these days, i would really hate a drastic further slow down of the engine.


Something that may interest you :cheers::
jslinux ;):
http://bellard.org/jslinux/
(mind you this is javascript, not java, but it is an example of what is possible on modern machines with an "inferior" programming/scripting language)

@Nuno

JFYI, and absolutely IMHO :cheers: I have rarely seen in my life a worse plan than the one you just sketched :w00t: :ph34r:, the good news :happy_dance: are that at least there is a plan (completely wrong and basically flawed from it's roots up :(, but still a plan :))

@Darijo
Why don't you write a simple "translation" program?
An example is the one talked about here:
http://www.911cd.net...pic=23408&st=21
that was removed from it's homepage and needed however (and IMHO) a re-vamp with added features.

@all
As seen from the outside, this thread appears as a way of drifting away from the actual issues, which are basically have something:
  • working
  • easily usable by non-expert
  • easily programmable and thus inviting more users to actually contribute with some .script
  • documented
to get to theories about "what would be nice to add" or "better ways to get to the same current chaos, only several months later and with a nicer approach" (something that will inevitably introduce such a number of problems and bugs that it will take ages to bring to the same - no offence intended - scarce level of documentation and functionalities of the current "engine").

Obviously and rigorously IMHOWDAHR (In My Humble Opinion WARNING! Dinosaur's And Hairy Reasoning :ph34r: ) a project should have an alternating life:
evolve/add features
consolidate/document
evolve/add features
consolidate/document
etc.

the:
evolve
evolve
evolve
evolve
etc.
approach without the needed consolidation is what makes everything either "vague" or "unreliable" or of "difficult" use.
I mean very possibly it is this that for many of the major contributors makes it "fun" or "interesting" and "drives them", but the experience with the "product" of the actual "end users" and of the "less experienced but willing new .script developers" will be (please read was, has been and is ;)) very, very complex and difficult, making a number of them soon "disappear", overwhelmed by the steep learning process needed.

If the idea is that of a think-tank and laboratory to experiment with new nice things at a "high" level, it's of course all right, but if it is that to give "to the masses" a reliable, easy to use and configure tool to actually build something, I am afraid that the chosen path is going in the wrong direction.

:cheers:
Wonko

#17 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 20 May 2011 - 12:09 AM

Not sure what this is about:

It is getting harder to work with the registry, getting harder to work in new formats (WIM), getting harder to manage binaries (32 vs 64 bits), harder to run programs (Administrator/UAC permissions).

Even if its true seems a feeble reason to change the architecture of winbuilder.

Write in .NET and you can be windows platform agnostic if you so chose. The .NET runtime will compile on the fly into the current OS architecture.

What is hard about wim's - MS provides an api that anyone can use plus utilities built into win 7. Psc and others have written wrapper utilities to avoid the licensing issues of the AIK utilities.

One prompt for elevation when you start winbuilder is all you have to put up with. On Linux if you want to do system level tasks then you have to switch to the super user.

#18 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10547 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 20 May 2011 - 06:33 AM

Something that may interest you :
jslinux

Cool! :happy_dance:

I have rarely seen in my life a worse plan than the one you just sketched

Thank you. Looking back I should admit that you make perfect sense. Also notice that you frequently complain about my world domination plans since 2005. :cheers:

the good news are that at least there is a plan

Yes, a good plan to set in motion for future years. I personally look forward to see the concept of interacting with winbuilder.exe externally as a web service available. Instead of being stuck to the provided User Interface of WinBuilder, other developers can just create a wrapper that suits better their needs.

For example, a simple interface with just a box to select the source files, a play button and a progress window. Good for projects not meant to be customized.

Even if its true seems a feeble reason to change the architecture of winbuilder.

Considering all the things that have changed in this feeble amount of time, I am ensuring that our architecture can progressively become flexible and robust to changes.


What is hard about wim's - MS provides an api that anyone can use plus utilities built into win 7.

Sure, keep on using them. I am working on a backup plan. If it behaves better than the MS API, so much the better.

Psc and others have written wrapper utilities to avoid the licensing issues of the AIK utilities.

I see native WIM handling as a challenge. If it brings benefits for the future over the current methods, so much the better.


Write in .NET and you can be windows platform agnostic if you so chose. The .NET runtime will compile on the fly into the current OS architecture.

That is a valid reason. I opted for not using a closed coding environment (again).

One prompt for elevation when you start winbuilder is all you have to put up with. On Linux if you want to do system level tasks then you have to switch to the super user.

As wise developers that we are, a good guideline for the future is aiming to reduce the level of administrative permissions required for building a boot disk, regardless of the OS.

:cheers:

#19 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 20 May 2011 - 11:55 AM

What level of functionality would you see your web interface providing? I presume it would be a much higher level than the single line of script? Something like RunScript or RunProject? I hope you are not proposing that when you press the big blue arrow in winbuilder that every line of script will be sent singly to the engine via the web interface.

#20 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 20 May 2011 - 12:04 PM

As I see it the internal architecture does not matter to the user. However what is paramount is speed of execution.

Psc make great speed improvements with the System,COMP80,OFF option.

Execution speed should be the next major focus of winbuilder development. Still along way to go in my opinion. Should not need to set an option to gain a 2 - 3 times improvement in project execution time.

Have to say I am yet to see a good Java app. One I use daily at work is the PVCS source control system. Java interface sucks big time. Java may be a good language for the UI however its hard to see how coding the engine in Java could produce anything like the current execution speed.

#21 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 20 May 2011 - 12:07 PM

Like Wonko said so eloquently, it's impressive, what can be done these days on modern hardware even with inferior programming languages.
This however does not make then any less inferior, imo.

When i run Win7 on a recent high end machine and XP on a computer from 2002, i can easily say that Win7 is a great improvement. It runs way faster.
If i run both on the recent high end machine, XP clearly takes the lead, but actually Win7 is not soo much lacking behind, to call it bad or inferior.
It's not until i run both on the old 2002 computer, that i really see the true picture. Win7 sucks big time compared to XP, performance wise.

In essence, choose a fast enough machine and you can make the crappiest programming look decent.

:cheers:

#22 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 20 May 2011 - 12:13 PM

The problem with your 2002 machine will always be drivers. Buy a new graphic card / sound card / printer etc and your chances of finding working drivers for any new hardware as time goes on will be less and less. Many hardware manufactures have given up writing / supporting XP drivers.

#23 paraglider

paraglider

    Gold Member

  • .script developer
  • 1729 posts
  • Location:NC,USA
  •  
    United States

Posted 20 May 2011 - 12:19 PM

The focus of a modern OS is not speed however it still needs to be adequate. It is all about providing a rich user experience.

Yes we could go back to the msdos days and run text mode programs from the command line.

#24 MedEvil

MedEvil

    Platinum Member

  • .script developer
  • 7771 posts

Posted 20 May 2011 - 12:29 PM

The XP-Win7 driver thing is mostly only clever marketing. I ran half a year ago a test with XP and Win7 drivers. Only the graphics card driver needed some patching, to stop complaining.
XP divers on Win7 though is a good deal harder, as not the drivers, but the OS complains. But also here, i was able to have mostly success.

The biggest problem with this cross Windows setups, are the driver installers. Those check the OS and complain without end.

:cheers:

#25 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10547 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 20 May 2011 - 02:15 PM

What level of functionality would you see your web interface providing? I presume it would be a much higher level than the single line of script? Something like RunScript or RunProject? I hope you are not proposing that when you press the big blue arrow in winbuilder that every line of script will be sent singly to the engine via the web interface.

The current functioning of WinBuilder does not change, my apologies if this was not clear in the first place.


What we add as novelty is the possibility of;
- retrieving and setting at any given moment of project execution the value of variables in a project
- call specific details such as the project log or the current script being executed
- Start/Stop/Pause execution of projects

A third-party programmer can in this manner interact with the WinBuilder.exe engine using the command line wget or other ways deemed appropriate. Nice for command line automation and also nice for better user interfaces to surface from other developers.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users