Hi all:

I'm new here, and first off, I'd like to say thanks to all the people who made the UBCD project
such a great success.

I'm using plain vanilla BartPE, with nu2menu. I use BartPe as a technician, which means that
I'm always at a different machine every day. Because of this, I'd like to be able to incorporate
the UBCD4WIN driver packs into my plain BartPe build. However, the clincher is that I want
to only install the driver packs for chipset, NIC, mass storage, and possibly USB. (I only need to be
able to fix machines in emergencies, not play sounds, or any other non-emergency activity.)

I'm concerned about using the normal method of installing the full driver packs, because:

1. I want to only install the drivers mentioned above.
2. I want to be able to undo or uninstall any changes installing the driver packs might make
to my PEBuilder environment (NOT the build, but the PEBuilder environment).
3. I want to learn something (so please-no answers just telling me to use UBCD4WIN)

I am a technician, but I have almost zero scripting skills, so I have trouble understanding
some of what the .CMD and .inf files do. That's why I'm asking.


Thanks in advance for any help.




Shplad

BartPE
Adding drivers

1.8 drivers final

Thanks, but...umm...you haven't answered my question, and none of your links
are specific to answering my question.

I know where the links are, or I wouldn't have been able to find
my way to this forum or to have built a BartPE disk, as I had earlier said I had.




Shplad

Both links answered your questions!
What do you not understand???

Joshua

Hi Shplad

If you extract the contents of the driver pack to a location outside the pebuilder folder tree
you can select which network card and SCSI/Hard disk drivers to include in your version of the project

location for network drivers -- Drivers\NET\

location for Hard disk drivers -- Drivers\SCSIAdapter\

Nvidia drivers seem to cause the most problems as drivers use files *.SYS with same name but different incompatible versions for different chipset versions.

Not sure what changes to Environment being caused by driver packs you are refering to.
To uninstall them remove file from folder drivers\... and rebuild project

Note the driver pack does not function like plugins.
PEbuilder processes the driver files from driver folder selecting the files it needs and ignoring those not needed. There are differences between the way drivers from NET and SCSIAdapter folders are parsed

(we need to be sure which driver pack(s) you are refering to. I presume you mean those collected by LittlBUGer)


regards
Mike barnes

I have two questions (none of which are answered in the links you gave me:

1. Are you saying I can just delete any folders from a driverpack that I don't need,
and the driverpack will function perfectly without any changes in code/form and that
there will be no consequences, either at build time, or when it comes time to boot
the Bart CD? .

2. You're saying there are no repercussions to the PEBuilder file/folder environment?
I thought using driverpacks overwrote certain of the XP source files. Is this not the case?
I don't want to find out after the fact that my PEBuilder environment has been irretrievably
changed just because I used a driver pack.

Thanks again.


Shplad

1. Yes. None of them are dependant on another. Each folder includes driver files only for that specific device.

2. Yes, there shouldn't be any changes. To the best of my knowledge, I don't think that any files are modified. I can't be certain though, because I do not completely understand the "driver integration" that Bart does with PE Builder. Some of the files included may have the same file name as the ones included with the XP install CD. If that happens, then most likely the files included in our driver pack has a more up to date file so it should work fine.

In conclusion and as a side note. Our driver packs have been around for close to 2 years now with few problems reported. Driver integration is not always perfect, usually because of the MANUFACTURER. For some reason some manufacturers use the same file name for devices. For example, nVidia has the same file name used for their nForce chipsets. nForce2 will only work with version 2.11, nForce3 will only work with version 2.33....etc., etc. These are not true numbers, just an example. So their driver method causes issues for us because there is NO simple way to include the different versions of a file with the same file name.

Let me try to cover a couple things quickly....

You might be thinking of the BTS style driverpack and not the offical 1.8 driver pack. The 1.8 pack only has NIC & Storage drivers included in it. USB requires a special plugin that can be taken from ubcd4win v3.

Pebuilder adds drivers from the \pebuilder\driver folder & combines the files to the output directoy & the needed hardware ids into txtsetup.sif. These drivers are all stand-alone & do not need each other, so you can delete them without problems unless that you need that specific driver later.

Pebuilder does not modify the SOURCE OS files that you use, but DOES modify the OS files in the output directory depending on what plugins are added/enabled or modified. You can always rebuild the outdir from your source after changing plugins & not have to worrie about the source being changed.

NIC drivers will require bartpe.exe -pnp OR hwpnp.exe to load properly.

Please post any specific questions you have, & we will try to answer them but you might STILL want to try a full UBCD4WIN v3 build & then just remove everything you dont find usefull. SORRY, just had to add that.

Great to know that as far as you guys know, it hopefully won't change my source files and/or
my PEBuilder build environment. I'll back up my current build environment and try it.

Eesh! Don't get me wrong guys-I'm grateful for both of your answers. It just seems to get more and more
complicated the more I investigate.

Which USB plugin is it that is taken from ubcd4win v3 that you recommend hilander? Which
driver packs do both of you recommend for NIC, mass storage and USB? I'm already trying to load
"USB+IEEE1394", but can't get it to load without errors. Is that what you mean?

Oh, and I still have no clue whatsoever what "bartpe -pnp" is. Is that a command-line
switch with which to launch BartPE?


Brad

bartpe.exe is a tool included in the default pebuilder download to offer some pnp functions.

bartpe.txt
HWPNP by Paraglider is far more advanced then bartpe.exe

The usb plugin is located in \plugin\driver\removable-storage
Use the entire folder for usb support. What error are you getting?

You will also need a function call to envoke runonce if you do not have an explorer type shell loaded.
3.0 uses GeoShell to envoke runonce.

This build & any other one that is this advanced is extremely complicated & has many layers of plugins that work together to provide a fully functional environment.

The profiles module of nu2shell is very poor. You can use peloader & my environment plugin to defeat this problem & get things working right.

I still recomend you start with our build & just chop it down to what you need instead of trying to figure out everything on your own as that can take a long time to do. For example this build is 2 years old now & has many advanced programers working on it. The Core alone took more than six months & is still in the beginning stages of development, more features will be added as time allows.

Aw c'mon...you're just trying to confuse me even more so you can convince me
to use ubcd4win, right?

Problem is, I've already got a plain vanilla Bart build, which I've tested, and even
had someone else help me work on in person, and I might have to throw away
a lot of that work to start all over again with ubcd4win. Because I'm no programmer,
I've been working on it for a long time. As you yourself pointed out, you can't just
start enabling plugins willy nilly-some of them will affect others-there will likely be
repercussions.

What you've written contradicts another answer that somone gave me on this same
website. They said that HWPnp is mostly used for non-critical drivers that don't have
to load at boot time, (as opposed to massstor, chipset and NIC). I'm not saying you're
right or wrong, just that I seem to be getting several different answeres. I still don't understand
why so many different methods and utilities are necessary just to get drivers to load.
Okay, I can understand some drivers need to load during boot and some don't, but
beyond that ....

You said:
"You will also need a function call to envoke runonce if you do not have an explorer type shell loaded."

In order to achieve what?


Thanks again.


Shplad

You can't go wrong following a developer's statements vs a standard member of the forum... hilander999 developed the core that took the project from a 2.x version to a 3.x version. This fact alone should be enough to convince anywone that is paying any attention.

Runonce is one of the many startup areas within Windows ( all Windows ).. it is used to initiate a program, function or other service. In the example provided.. ie Bartpe.exe or HwPNP.exe.. it starts the plug-n-play to detect devices and allow their drivers to therefore load, that were not started during earlier steps of the startup.

Why beat a dead horse? Give the project a try. You might find that most of your issues have already been addressed.
No need to reinvent the wheel....

Case in point: The USB plugin(You Want) uses registry entries that are loaded into the running pe build by a call from RunOnce. Explorer.exe &/or Geoshell.exe both envoke RunOnce statements. An alternative is to search every plugin for runonce & do the same commands in a script at boot time during autorun.cmd.
Have you tried this build yet? What are you loosing by NOT trying it? Adding things you already have is not that hard & if you were to try it you might wonder why you are trying to build a vanilla pe from the ground up.

Just make sure you use a new directory that does not conflict with any other build & you have no problem.
You can always delete it latter.

Critical drivers are loaded during the txtsetup phase of the boot process=mass storage & chipset.
Non Critical drivers (to the system functions)= NIC/Graphics/Audio..ect...

bartpe.exe -pnp does a basic pnp function call & loads the NIC drivers. HWPNP is much better.

I believe Hilander999's SystemCore plugin alone is around 25,000 lines (and many hours of expert coding) but it's up to you to decide which way would be more effecient for your situation.

I guess because I'm not doing what some of you want me to do that in your eyes,
I'm just difficult. So be it. But I have certain things I want to do. Maybe one of them is to
learn something, rather than just build and go. I appreciate that you guys are trying
to make my life easier, but as I said, I would like to do this the plain vanilla BartPE way.
I don't honestly believe I can just take my existing 24 plugins and dump them into UBCD4WIN and
everything will just work. Having a friend who is a QA tester has convinced me of that.
That's not to say I won't try it...I will, but I'd like to go vanilla first.

The only problem with HWPnP is that I'm left with umpteen yellow question marks after I run
it, with no indication of which node is which hardware device. That means I have no idea
which drivers to load where.

Just to clarify, you're saying that "bartpe -pnp" is a statement that is put in the runonce
node in the registry so critical drivers are loaded during boot?

You're saying NIC drivers are not considered critical and therefore don't need to be loaded
at boot time? That contradicts another post where a question was answered for me earlier.
Can you see why I get confused? I'm not saying you're wrong, just explaining why there
has been so much confusion for me.

Thanks again.


Shplad

So, what is it that you want?

Do you want us to take the load off your shoulders and make your stand alone BartPE build with 24 plugins work with complete hardware/Software support as UBCD4Win does but not use UBCD4Win?

@hilander999
You really need to get a PayPal account...

Once again.. critical drivers are loaded during the txtsetup phase of booting. NIC are loaded after the shell starts AT BOOT TIME.



@Tom

I know.

Looks like the tone has become decidedly unfriendly around here, so I'll say thanks
to all you and duck out. This seems to be becoming increasingly more common in
these forums lately. I'ts too bad that increasingly, some people only want to answer
questions 100% on their own terms, or only if others are at their skill level. No one is putting
a gun to your head to ansers these questions. If you don't like my questions, why not let
someone else answer them. Really, I didn't deserve to get insulted. Just because I wanted
to do something that wasn't the most convenient thing for you (or me) doesn't make me
diffcult/stupid as some of you have chosen to imply.

If I knew everything about BartPE, WTF would I come to a forum? I guess this forum is only for
BartPE experts to help experts, huh?.

Thanks to all of you, but a special thanks to those of you who didn't talk to me like I was
some kind of moron.


Shplad

We used to have everything seperaated into plugins but incorporated many things into the systemcore plugin in 3.0 so there's no push-button solution to what I think you're wanting. The only thing I can suggest has already been suggested, try it and see but there are no guarantees as that's not what is was developed/tested for.

pcuser:

Thanks for your reply.

So I followed instructions carefully, and this is what happened. (Note I'm not looking
for help, just wanting to share the report. For now, UBCD4WIN may be a no go for me.)

-Extracted all UBCD4WIN V. 3.0 files
-Moved about 6 of my plugins to the UBCD4WIN plugins folder. None of them, that I know of,
are plugins which create any conflicts.
- Enabled and disabled various plugins, according to my needs. Did NOT disable any critical
plugins, at least according to what I saw. Mostly disabled tools for things like disk partitioning,
password cracking and other related tools.

At least 50% of all the plugin programs either didn't run, or crashed with an error...something
regarding the desktop folder in the profile not existing or being missing.

At least 20 or 30% of the plugins I chose, which came with UBCD4WIN, did not even show up
in the menus.

UBCD did not recognize my Nforce4 NIC properly, and couldn't seem to after boot either,
no matter which tool I tried. Yes, I'm aware that the nvidia driver architecture can be troublesome,
but I thought the devels had claimed to have this largely resolved by now. Other people claim
to be able to get it working using UBCD4WIN.

Many of the menu categories, such as Programs, showed up 5 or 6 times in my Geo menu.

As a coincidence, I was editing my own system registry, to clean out some unused gunk. I noticed
immediately that during the build process, UBCD4WIN had added quite a few registry keys
to my own workstation's registry (the one on which I performed the build process.) Whah?

I could not run Nero, since UBCD4WIN's other CD burning programs insist on
loading the Adaptec ASPI layer.

As I said, I'm not looking for help, I just wanted to report back to let you know that trying UBCD4WIN
didn't work quite as easily as some of you had suggested it might.

Now I'll go ahead and await the answers that find a way to blame it on me somehow.


Ciao for now.

Boy, I need a beer now after reading all of this crap stuff.

I don't have the energy to cover everything, but I will share a few things:
1. I still wonder at times why we try to convince people to use the project? It really does us no good really?? All the project gives us is high hosting costs, and headaches when trying to help users. I wonder if the I had spent the hours on my kids instead of helping people with this project, would they be better behaved? Doubt it, they have my genes!!! Okay, I apologize for being a jerk.

2. There appears to be XML issues with your plugins. If you view your ubcd4winbuilder.log file, you will find an XML error line. You then have to search your nu2menu.xml file located in the "BartPE" folder for that line.

3. All of the fixes will probably take too much of your time and will not seem to be worth it. I would honestly say to just give up and use your vanilla build.

That's kinda messed up. I don't think in 2 1/2 years I've ever told anyone to just give up, but there has already been too much fighting in this post. I just think there is "bad blood" now and no matter how hard we tried, I don't think either of us would be able to work together to fix up your build.

I do think you did something wrong... but some of it was expected to some extent anyway.

Duplicate menus and possibly the missing menu items are likely caused by an XLM in one of the added plugins not following UBCD4Win's menu layout.. these are usually easily fixed by some minor adjustments. This is one reason to pretest any ( BartPE or UBCD4Win ) build in a VM enviroment. I also like to only add one plugin at time to make it easier to identify the "culprit" easier.

Nforce nics are an issue no matter what ... but the fix is easy.. remove the other nVidia NICs and they should work unless your system has an altered driver that it must use. nVidia uses the same filename across the various versions so the last one that gets copied is the one that works... This can also happen with the video drivers as well... same reason.

The crash's.. again probably something conflicting in a plugin you added... an unaltered UBCD4Win ( with just enabling/disabling its own ) won't do that. Again a good reason to pretest in a VM and only add one at a time until tested.

There is only one way that any PE registry entries end up in your system's registy.. if you clicked on one of the inf's in the project... it can not happen any other way.

Can't this also occur if you run a program from the BartPE or UBCD4Win folder on the hard drive while in windows (not PE)?

The only time I've had duplicates in the menu is when I've used Plug-Ins that had *.* statements instead of listing the files/folders and trying out plug-ins without checking the included XML file for format differences..

And on a side note: Not everyone that frequents this Forum is a BartPE/UBCD4Win expert - I'm very far from that myself - but when your adding your own programs/plug-ins you have to expect some work/learning to get them to work. These guys are working hard on their spare time to help all of us out with a great product that will work 99.9% of the time (out of the box so to speak) - IF THE DIRECTIONS ARE FOLLOWED. AND IT'S FREE.

One thing I forgot to mention also is the fact we are on the borderline of being offtopic. The title talks about drivers, but now we are fixing "addon" or "personal" plugins.

I again apologize for being a bit harsh earlier tonight, I'm in a "mood." Sometimes I think my wife is sneaking me estrogen or something because of these damn mood swings!! Then I just stop for a second.....thinking.....and remembering.....I'm just F'n nuts!!!!!!!

SteelTrepid:

Much appreciated. Wasn't meaning to trash or criticize the project. It's obvious the
work you've put into it. I just wanted to show that things don't always work in
vivo the way they work in theory.

Thanks again for the help.


Shplad