Re: [Freedos-user] re: Not to flame but let others know ...

2006-04-21 Thread Schumacher, Gordon
# Date: Thu, 20 Apr 2006 23:42:29 +0100
# From: Shane M. Coughlan [EMAIL PROTECTED]
# To:  freedos-user@lists.sourceforge.net
# Subject: Re: [Freedos-user] re: Not to flame but let others know ...
# Reply-To: freedos-user@lists.sourceforge.net
#
# Let's just get back to work, eh?

Nothing to see here, move along!  :)

It's kinda sad that an argument is what has generated the most traffic
on this list in a long time, wot?


---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] re: FreeDos a good choice for me?

2006-04-19 Thread Schumacher, Gordon
# On Wed, 19 Apr 2006 13:25:05 -0400, Scott Mayo [EMAIL PROTECTED] wrote: 
#
#  Since I've joined the list, I've had one or two people suggest other
#  operating systems, and a bunch of people bickering of the ownership of
#  some wretched piece of software. No one has stepped up and suggested that
#  FreeDOS is going to do what I need. Should I take this as a hint that I'm
#  looking at the wrong OS?

It could, certainly - but in this case I think it's probably not the best
choice.  You've said that you almost don't need a full OS - which suggests
to me that something more like a microkernel or an RTOS would better suit
your needs.

# Date: Wed, 19 Apr 2006 19:38:20 +0200
# From: Florian Xaver [EMAIL PROTECTED]
# To: freedos-user@lists.sourceforge.net
# Subject: Re: [Freedos-user] re: FreeDos a good choice for me?
#
# I also don't like that someone makes publicity for other operating 
# systems. Please don't do it ;-)

Just trying to answer the question fairly; on the flip side, I've got a
largish company that's using FreeDOS as the best solution for a whole
bunch of stuff.  That's gotta count for something right?  :)


---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


[Freedos-user] RE: Freedos-user digest, Vol 1 #786 - 7 msgs

2006-04-17 Thread Schumacher, Gordon
# Date: Sat, 15 Apr 2006 16:11:23 -0400 (EDT)
# From: Scott Mayo [EMAIL PROTECTED]
# To: freedos-user@lists.sourceforge.net
# Subject: [Freedos-user] FreeDos a good choice for me?
#
# I'm looking for an OS to run on an embedded system (a 586 based PC104)
# board. What I need is pretty simple:

Have you looked at eCos yet?

http://ecos.sourceware.org


---
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


Re: [Freedos-user] Dual Boot WindowsXP and FreeDOS - Alpha testers

2006-01-24 Thread Schumacher, Gordon
Mark Bailey [EMAIL PROTECTED] wrote:

# Date: Mon, 23 Jan 2006 18:32:55 -0500
# From: Mark Bailey [EMAIL PROTECTED]
# To: freedos-user@lists.sourceforge.net
# Subject: Re: [Freedos-user] Dual Boot WindowsXP and FreeDOS - Alpha testers 
needed
#
# I was thinking a bit more about automating this.  We
# MIGHT be able to grab some stuff from a Linux installer
# to automatically, under carefully defined conditions,
# shrink the NTFS partition and create a new fat32
# partition.  AFAIK, it can't be done under DOS at all.
# Partition Magic just doesn't reliably work on NTFS
# partitions as of 8.02 and XP Service Pack 2 (or
# possibly, SP 1).  And, Partition Magic is expensive
# and has a restrictive license (use on one computer,
# blah, blah, blah...).

Why not use ntfsresize?  One could see about trying to get *that* built
under DJGPP... or have I just pretended to be 'Q' and said Simple,
change the gravitational constant of the universe! :)

# Judging from the response to Version 1.0, though,
# only one FreeDOS user was even interested in dual
# booting a new machine.  It appears everyone else
# has already figured out how to meet their
# requirements.  Most of the folks I know use
# old, dedicated machines to run DOS.

Well, I do this - in fact I'm triple-booting SuSE 10, XP, and FreeDOS -
and I even have XP recognizing its own drive as C: (which is the sneaky
part) but I personally found it to be easy, if slightly convoluted.

1) Boot off of the SuSE CD in rescue mode and create an ext3 boot
   partition as partition 1.
2) Reboot onto the Windows XP boot disk and create a FAT32 partition, being
   sure to leave space after the end of that partition for your Linux root
   and swap partitions.  Do not let it continue the install past formatting
   the partition.
3) Reboot into SuSE rescue and delete the ext3 partition.
4) Reboot into the XP installer.  Let XP install.  Since there are no other
   partitions on the disk, it will identify the single partition as C:.
5) Install FreeDOS, onto the same FAT32 partition.  FreeDOS will see that
   XP is installed, and instead of replacing the boot sector it will put
   the boot sector into a file named FREEDOS.BSS and add itself to the
   BOOT.INI file for the NT boot loader.
6) Install SuSE, recreating the boot partition as before.  For bonus points,
   remove the FreeDOS entry from BOOT.INI and add it to GRUB's menu.lst, so
   that you have a single boot menu :)

For a dual-boot XP/FreeDOS install, skip steps 1-3 and 6, and simply install
XP first.  You could I suppose install XP and FreeDOS to separate FAT32
partitions if you wanted, though I haven't done that.


---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid3432bid#0486dat1642
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


RE: [Freedos-user] Methods against harddisk password troubles

2005-04-22 Thread Schumacher, Gordon
# Message: 2
# From: Eric Auer [EMAIL PROTECTED]
# Date: Thu, 14 Apr 2005 12:54:51 +0200 (MEST)
# To: freedos-user@lists.sourceforge.net
# Subject: [Freedos-user] Re: Methods against harddisk password troubles
# Reply-To: freedos-user@lists.sourceforge.net
# 
# The Heise article writes that for example going to standby / suspend
# triggers a reset at wakeup. I can confirm that as far as ACPI docs
# have an opinion about it... The CPU has several sleep states, and in
# the deeper ones, all state / register information is lost, so you
# have to save it to RAM first, and the BIOS will jump to your wake-up
# handler to let you restore it when the system wakes up. Note that e.g.
# FDAPM does not support this, as you have many system programming and
# exotic registers to save if you want to save ALL state of a 
# modern CPU.
# So FDAPM only supports light stop CPU sleeps and poweroff in ACPI,
# the deeper suspend sleeps are only supported with APM BIOS help.

I would be *extremely* surprised if this was ever a hard reset, because
as noted earlier, there's not a standardized way to perform such a
reset - and in fact nearly every ATA controller chip on the market
provides absolutely no way to do it.  There would have to be extra
hardware between the controller chipset and the connector on the
mainboard.  IOW, if the spec for some reason required a hard reset,
the capability for it would exist in the controllers because the
industry would demand it (what?! you want us to add components, just
so that we can meet some stupid spec?!?)

# Could you also add some explanation about the unlocking? Can I set a
# key without implicitly locking the disk at the next boot? I mean, a
# key which is just there and has to be provided before you can set the
# locking mechanism to another key? That would avoid the have to boot
# from diskette to get access to the harddisk problem of fully locking
# the disk, and the everybody can set a random key at the same time.
# Only remaining problem would be, unless I activate freeze state at
# boot, that somebody might be able to activate the lock - with my key
# - w/o having to know the key. Depends on how things are implemented.
# Still no real problem, I could boot from diskette one time and
# reconfigure to key set but disk not locked state. Again, IF such a
# key set but disk not locking state exists.

No, that's not how it works.  If there's a password set, then security
is enabled.  What you're describing is basically what Security Freeze
is meant to accomplish (but it's at the BIOS level, not the drive
level).  The BIOS should contain a switch for security mode frozen,
preferably enabled by default.  In the BIOS, you can set a password
because the Freeze command hasn't been issued yet.  Perhaps three
settings for the switch, On (default), Off (this boot), and Off?

# About user / admin keys: I assume you need the user key to change the
# user key and the admin key allows you to change both keys. I 
# also assume that you need the admin key to block the admin key can 
# override thing.
# So basically I can set an admin key only, and whenever some 
# trojan / ... messes with my user key, use the admin key to override.
Yep.

# Of course it would be really cool to have an user interface for all
# that in the BIOS rather than having to boot from diskette :-|.

And, that's the problem: that's where it really belongs.
It's as if a carpenter building a house simply didn't bother to buy
the tools to do the job right, even though the hardware store sells
them: it's really not the HW store's fault...

# Of course if the BIOS would store the key in CMOS, it would again
# be trivial for a trojan to replace my key, at least given that
# most people use one of the same few quasi-monopoly BIOS
# brands. So the BIOS would provide me with a disk locking key 
# prompt ideally.

You're exactly right - which is why it doesn't work that way.

# PS: No need to CC me in the reply, I am on freedos-user 
# anyway. And please edit the subject to be Methods against
# harddisk password troubles instead of the subject of the
# digest ;-).

Yeah, I realized that last about five seconds after I hit send :-P


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


[Freedos-user] RE: Freedos-user digest, Vol 1 #430 - 4 msgs

2005-04-13 Thread Schumacher, Gordon
# Message: 4
# From: Eric Auer [EMAIL PROTECTED]
# Date: Tue, 12 Apr 2005 23:14:34 +0200 (MEST)
# To: freedos-user@lists.sourceforge.net
# Subject: [Freedos-user] Methods against harddisk password troubles
# Reply-To: freedos-user@lists.sourceforge.net
# 
# 
# Hi, as neither harddisk makers nor BIOS makers really seem to
# care about users getting locked out of their own disks, you
# might want to have a look at this article:
# 
# http://www.heise.de/ct/english/05/08/172/
# 
# Years ago, IDE / ATA harddisks started to support a password lock
# feature, but nobody really used it. Well, probably the X-BOX is
# using it. Anyway. The problem: A virus or trojan can set a random
# password for your harddisk, with the effect that you never get back
# access to your data. If you are lucky, you can use the reset
# password and format disk function to get at least the hardware back.
# 
# As far as I know, no harddisk vendors have yet taken the effort to
# add a simple jumper to block password changes - really a pity. That
# kind of jumper works pretty good to protect your flash BIOS on a lot
# of mainboards out there...
# 
# However, at least a few BIOS makers have included freeze password
# access at boot time, but the freeze only has effect until the
# next disk reset. If a trojan or virus can get access to the raw disk
# to mess with password features, then it will probably be able to
# trigger a disk reset, too. Again zero protection :-(.
# 
# The only real protection at the moment is: Set a disk password
# yourself. But then, you need a BIOS which gives you an interface
# to unlock the disk every time you boot... Or you have to boot 
# from diskette or USB
# to unlock your harddisk every time you boot. Really crappy
# situation. Especially given that this potentially disastrous
# feature got introduced roughly SEVEN years ago!
# 
# In Linux, you can use hdparm to control the password feature,
# and in DOS, you can use tools like ATAPWD.
# 
# Eric

(I've done some research since I got your last message, Eric... I
didn't blow you off before.  I'm just crazy busy.)

Actually, that's not true; the only way, according to the ATA-7
specification, to quit the Security Freeze Lock state is to power
off the drive:

--
The SECURITY FREEZE LOCK command shall set the device to Frozen
mode.  After command completion any other commands that update the
device Lock mode shall be command aborted.  Frozen mode shall be
disabled by power-off or hardware reset(1).  If SECURITY FREEZE
LOCK shall be issued when the device is in Frozen mode, the
command executes and the device shall remain in Frozen mode.

Commands disabled by SECURITY FREEZE LOCK are:

- SECURITY SET PASSWORD
- SECURITY UNLOCK
- SECURITY DISABLE PASSWORD
- SECURITY ERASE PREPARE
- SECURITY ERASE UNIT
--

(1) A hardware reset is a *hard* reset, which is triggered by
driving pin 1 low - not something possible by issuing a command
to the drive.  There are are *maybe* one or two plug-in
controllers out there on which it is possible to trigger a hard
reset on the cable (NOT the drive), but in order to do that you
would have to have the access level of a driver (ring 0), and have
intimate knowledge of how *that particular* card would go about
it.

I am hereby stating that the following is ONLY my opinion - I am
not nearly so lofty as to speak for Maxtor :)
That said... it seems to me that there's already a mechanism in
place to lock the drive.  That most BIOS manufacturers aren't
bothering to implement it is hardly the HD manufacturers' problem.
It would make sense to me to take it up with the BIOS writers (and
perhaps the c't article will go some ways to encouraging that!)
It wouldn't be hard for the BIOS writers to do this - I've seen
several that do much the same thing with Auto-Acoustic Management.

The reason I can think of that the manufacturers are unlikely to
want to add a jumper - besides the fact that the ATA spec has
already addressed this - is cost.  Adding a jumper is actually a
non-trivial thing.  It's not just the jumper itself; I/O lines
into the ASIC have gotten to be at quite a premium.

Anyway, my quick take on the matter (and hopefully clearing up a
misconception as to how easy it would be to bypass).
-- 
Gordon Schumacher
Tools Group, Maxtor Corporation


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user


[Freedos-user] RE: Freedos-user digest, Vol 1 #405 - 16 msgs

2005-03-18 Thread Schumacher, Gordon
 From: Kristaps Kaupe [EMAIL PROTECTED]
 Organization: NSS
 To: freedos-user@lists.sourceforge.net
 Subject: Re: [Freedos-user] Compilation with DJGPP using RHIDE
 Date: Fri, 18 Mar 2005 14:49:12 +0200
 Reply-To: freedos-user@lists.sourceforge.net
 
 I had problems with DJGPP (long compile times, mystical error messages)
 until I removed FreeDOS EMM386 from my CONFIG.SYS.

Well, one thing that comes to mind is that (at least) Microsoft's EMM386
affects how the DPMI host allocates memory - I don't know if the same
will be true of FreeDOS's, but we found some issues where it did
definitely negatively impact the performance of DJGPP-compiled apps (of
which RHIDE is one of, of course).


---
SF email is sponsored by - The IT Product Guide
Read honest  candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95alloc_id396op=click
___
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user