Motherboard Forums


Reply
Thread Tools Display Modes

"Pre-boot" applications

 
 
J de Boyne Pollard
Guest
Posts: n/a
 
      09-19-2007, 02:21 PM
RP> As for "not to drives directly," this eliminates some software
RP> tools from being written. Simple OSes such as DOS have
RP> many disk testing, disk formatting, and memory testing
RP> programs written by users and commercial companies. Windows
RP> and Linux, due to security, don't have such programs written
RP> for them. If they have programs with such functionality, they
RP> came with the OS and were written by the OS vendor.

The security aspect is not who wrote the program. It is whether
applications-mode code is permitted by the operating system to perform
the necessary low-level hardware access. That applies _irrespective_
of whether the utility programs were written by the operating system
vendor or by someone else. Operating systems such as Linux and
Windows NT impose restrictions upon what applications mode code can
do, with respect to such things as direct I/O access to DASD.
Operating systems such as MS/PC/DR/Free-DOS do not.

In years gone past, utility programs such as you describe would as a
consequence of this often come with versions of MS/PC/DR/Free-DOS on
floppy disc, which one would boot and then run the (DOS version of
the) utility program. (Partition Magic used to employ DR-DOS on its
"emergency boot" discs, for example.) Nowadays, modern firmwares have
sufficient support to enable such utility programs to be written as
standalone executables based solely upon firmware services, without
need for any operating system to be bootstrapped and without need for
the utility program vendor to supply an operating system on a utility
disc along with the tool itself. That is the way to proceed nowadays
if one wants to write a utility program for hardware testing,
diagnosis, update, and repair. That is the way that people are
proceeding. For examples:

* Intel publishes EFI executables for partitioning discs
(DISKPART.EFI), formatting FAT volumes (EFIFMT.EFI), and repairing FAT
volumes (EFICHK.EFI) -- <URL:http://intel.com./technology/efi/
diskutil_overview.htm>.
* The tool to update the firmware for an HP Smart Array P400
Controller is an EFI executable named SAUPDATE.EFI -- <URL:http://
docs.hp.com/en/AD397-9001A/ch01s03.html>. In fact, HP Integrity
machines come with a whole raft of EFI tools on a utility disc --
<URL:http://docs.hp.com./en/AB216-90001/ch04s06.html>.

 
Reply With Quote
 
 
 
 
Rod Pemberton
Guest
Posts: n/a
 
      09-19-2007, 08:45 PM

"J de Boyne Pollard" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> RP> As for "not to drives directly," this eliminates some software
> RP> tools from being written. Simple OSes such as DOS have
> RP> many disk testing, disk formatting, and memory testing
> RP> programs written by users and commercial companies. Windows
> RP> and Linux, due to security, don't have such programs written
> RP> for them. If they have programs with such functionality, they
> RP> came with the OS and were written by the OS vendor.
>
> The security aspect is not who wrote the program.


Never said that.

> It is whether
> applications-mode code is permitted by the operating system to perform
> the necessary low-level hardware access.


That's exactly what I stated.

If you hadn't snipped some of Matt's and my prior context, or if you'd
followed the entire conversation instead of responding to the end of it,
maybe you would've understood that we were talking about OS functionality
such as low-level hardware access.


Rod Pemberton

 
Reply With Quote
 
 
 
 
J de Boyne Pollard
Guest
Posts: n/a
 
      09-21-2007, 02:22 PM
RP> As for "not to drives directly," this eliminates some software
RP> tools from being written. Simple OSes such as DOS have
RP> many disk testing, disk formatting, and memory testing
RP> programs written by users and commercial companies. Windows
RP> and Linux, due to security, don't have such programs written
RP> for them. If they have programs with such functionality, they
RP> came with the OS and were written by the OS vendor.

JdeBP> The security aspect is not who wrote the program.

RP> Never said that.

The last two sentences of yours quoted above have a suspiciously
strong resemblance to saying precisely that.

JdeBP> It is whether applications-mode code is permitted by the
JdeBP> operating system to perform the necessary low-level
JdeBP> hardware access.

RP> That's exactly what I stated.

No, it really isn't what you stated in any way at all. You didn't
write that "due to security" was a matter of hardware access. You
wrote that it was that the programs "came with the OS and were written
by the OS vendor". We aren't clairvoyant. We can only read the text
that you actually wrote.

 
Reply With Quote
 
Rod Pemberton
Guest
Posts: n/a
 
      09-21-2007, 10:31 PM

"J de Boyne Pollard" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> RP> As for "not to drives directly," this eliminates some software
> RP> tools from being written. Simple OSes such as DOS have
> RP> many disk testing, disk formatting, and memory testing
> RP> programs written by users and commercial companies. Windows
> RP> and Linux, due to security, don't have such programs written
> RP> for them. If they have programs with such functionality, they
> RP> came with the OS and were written by the OS vendor.
>
> JdeBP> The security aspect is not who wrote the program.
>
> RP> Never said that.
>
> The last two sentences of yours quoted above have a suspiciously
> strong resemblance to saying precisely that.
>


Nowhere did I say the security is due to those who wrote the program. I
said, due to security, some programs aren't written for an OS by users and
commercial companies (anymore). If they are written for an OS, they will be
written by the OS vendor because of security. Basically, you've reversed
the meaning of the sentences.

> We aren't clairvoyant. We can only read the text
> that you actually wrote.
>


If that were true, you'd have gone back and read the entire thread. You'd
have known that context exists relative to the current paragraph which
didn't make it into the current post.


Rod Pemberton

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
\Applications and ~\Applications AES Apple 1 03-20-2005 02:52 AM
Re: Can applications in /Applications be put into subfolders? Bob Harris Apple 1 03-20-2005 12:46 AM
Re: Can applications in /Applications be put into subfolders? Andy Hewitt Apple 2 03-19-2005 11:45 PM
Re: Can applications in /Applications be put into subfolders? KYL Apple 0 03-19-2005 07:45 AM
Music applications - IC7-G and midi problem under ACPI ExaltedWombat Abit 0 07-24-2003 06:20 PM


All times are GMT. The time now is 11:18 AM.


Welcome!
Welcome to Motherboard Point
 

Advertisment