Frank,
Just to clarify, the ArcPath doesn't directly match to a drive letter. I mean your rdisk(1)partition(1) could've gotten mapped to E:
drive letter, for instance, if you happened to have one or more CD-ROM drives. It also depends on how the disk and drives connect to
IDE ports and etc. It may also depend on BIOS disk enumeration (the implementation itself) and how ntdetect transfers that info to
the kernel (in general it shouldn't mater but there are some bugs there that only appear on certain hardware).
There is quite many variables there and some of them are described in some MS KB articles (search this NG archive, I posted a few
related links). Again, although I am a bit familiar with the rules there, I am usually slacking there and check the FBALog.txt to
verify what drive letter I need to set up in the TD. And, btw, to have that very first FBA run to get the FBALog I can always build
a very minimal image like Minlogon Macro and it won't even require platform support (TAP output, etc.) but will still enumerate all
the disk level devices on the target hardware during FBA.
Many of us here prefer creating a separate thread per issue (to simplify the search index of the NG) but I'll answer yours here.
1) There are no "standard" procedures in embedded world. All embedded devices are different and provide different access to
hardware. Typically it is easy enough to take out the hardware local storage (HDD, CF, FD, etc.), put it in another PC and transfer
(xcopy) the image there.
However, a bit of caution here: you must [better off] prepare the media - partition and format - on the target hardware preferably
with the BIOS version you are going to use in the field. Reason is disk geometry parameters of MBR and boot sector records that may
get set wrong if you partition the storage device on a different PC. (Well, generally speaking you can *format* the media on a
different PC but just be careful with the tools selection).
For an industrial PC I can barely imagine situation where you are not going to be able to work with the hard disk offline (plugged
in a different PC). But if that's still the case and, as you mentioned, you've got another OS (XP) running on that PC, you can
always remote-in that OS and copy over the image there via a USB mass storage device or network or else. You mentioned FTP so I
assume that also available to you and can definitely be used. Just keep in mind that you will have to move the image bits to a
proper location on the target PC afterwards anyway.
Most of the techniques on how you can deploy your image are well described in the documentation:
http://msdn2.microsoft.com/en-us/library/ms932924.aspx.
2) I'll leave the answer to this question to Sean
But if you take a look at his website you'll find lots of info about his XPe books.
3) If you suspect the power can be interrupted for your target PC in the field and you don't have UPS or similar to work around that
then you might be interested in a few technologies XPe has built in. Read about those in the XPe documentation:
- EWF/FBWF - protecting the storage media with write filters will make it more reliable for the system to recover:
http://msdn2.microsoft.com/en-us/library/ms912906.aspx,
http://msdn2.microsoft.com/en-us/library/aa940926.aspx.
- Headless support - this is what you'll definitely need since no console devices are attached to or supported by your hardware:
http://msdn2.microsoft.com/en-us/library/ms932872.aspx.
- Don't include Safe Mode and Dr. Watson components in your image. (
http://msdn2.microsoft.com/en-us/library/ms940820.aspx)
- Setup the system crash dump procedure to restart the PC automatically when a GPF occurs. Set the following reg.entry:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl],"AutoReboot"=dword:1
- Get rid of all [most of] system popups and message boxes that may get your system UI unintentionally locked:
http://msdn2.microsoft.com/en-us/embedded/aa731206.aspx,
http://msdn2.microsoft.com/en-us/library/ms933122.aspx.
- It often makes a sense to create your own custom shell for our target XPe OS where you can control the UI behavior (to make it
more headless appropriate) and get rid of Explorer Shell that is not really headless friendly:
http://msdn2.microsoft.com/en-us/library/ms913692.aspx.
4) Run time licenses are not connected to the DevKit license. You have to purchase a runtime license that covers all your devices
where you run the XPe image you create.
If you plan to use the 5 dev PCs to dual boot to an activated (licensed) XPe image then you'd need to purchase 55 licenses. If not,
only 50.
You XPe distributor should be able to perfectly explain your that.
5) Hmm.. Not sure why you don't compare VB6 to VB.Net? That's be more appropriate comparison.
Usually the selection of the programming language is dependent on factors different or above than just the final PC configuration
and price. More important factors would be:
- What language you are already familiar with (or with what language you are a better programmer). The "better" justification is
more related to what the final product quality you are targeting, how difficult the main application would be to program and what
time frames you set for the project. Keep in mind that XPe is more a RAPID development platform.
- How many off-the-shell application components are available to you out there (freeware or shareware source code, OCX
components, .Net 3rd party components, etc.) to meet your application logic and requirements. With the beasts like .Net you are
leveraging huge framework library and that saves you lots of time.
- You can make your XPe image footprint much smaller than a regular full blown XP Pro. Even with .Net (2.0) you could
theoretically come up with a 200-250 Mb image. This however depends on your application dependencies. More it requires, more RAM it
takes. I'd say 500Mb is plenty of RAM there to even run a medium weight .net app.
- What DB component you are referring to? If it is Jet (MDAC), your app may not be that RAM resource consuming. However, if you
plan on SQL server (MSDE or SQL Express) and your query results would be heavy enough to fill up the RAM cache quickly, you'd need
more RAM.
- If you plan on putting lot of time in optimizing the image and main application RAM consumption and performance, often
languages like C/C++ are a better choice. Obviously, would require some programming skills in that language then.
