Cool folks.  Although.....

You somewhere it all went wrong.  We got too used to, too dependent on
layering and complexity.  I blame MicroSoft mostly, but the greed in
general in the industry and people getting in over their heads for
money and prestige is the main factor.  Patch it, hack it, do whatever
it takes to get to market on time and on budget and hold our market
share.  We've kind of gotten used to Dog's Breakfast software.

If I thought I had the years it would left in this life I'd write my
own OS from scratch and make it a lot simpler and faster than anything
we have today.  I've learned that Windows is slow because MS likes to
buffer things, have several copies of everything in memory.  Something
to do with safe programming for the mentally challenged I think or
just an old persistent patch thats been forgotten about or ignored.
Maybe a work around for some bug or flaw in Intel CPUs.  Maybe they
don't multi-task so well after all! (Its kinda contrary to the basic
design of digital CPUs, they are serial devices, thus the multi-cores
now.)

Well keep at it folks.  I hope you don't end up with something as
crappy as Windows in the end. Make KISS the holy grail or you will!
Tough to keep it simple with the hardware manufacturers riding the
money train too

Charlie B.

On 1/2/14, Jim Michaels <[email protected]> wrote:
>
>
>  hi... is there a chance it could work with any sector size, so that it
> doesn't have to be modified when things change again latrer? that could be
> extremely useful, since worm drives have 512, 1024 byte sectors, Advanced
> Format drives have 4096 byte sectors, and drive manufacturers are likely to
> increase this value as time goes on. so having something that can handle a
> variable number of sectors would be best.
>
> in fact, I wish djgpp could be redone too if it has those same
> limitations...
>
> this is a very nice Christmas present! cool! usb disks! I like this!
>
>
>
>>________________________________
>> From: Bertho Grandpied <[email protected]>
>>To: [email protected]
>>Sent: Sunday, December 29, 2013 3:44 PM
>>Subject: Re: [Freedos-devel] 4, 096 byte sectors and DOSLFN, UIDE...
>> question
>>
>>
>>
>>Bernd Blaauw <bblaauw@ho...> wrote on    2013-12-29 19:44...
>>
>>
>>>Would you be able to test your driver against the ASPI.SYS listed at
>>[ http://bootcd.narod.ru/index_e.htm ] ?
>>
>>Probably not directly. If I read and understand the description at that
>> site correctly,
>>that seems to be an ASPI driver for ATAPI devices, mostly optical like CD.
>> Those
>>devices wouls usually have 1024 byte sectors, wouldn't they ? Also, they
>> aren't "FAT"
>>formatted devices.
>>
>>In its current state, my driver - actually, more of a proof of concept -
>> will only mount FAT partitions
>>from (something that behaves as a ) R/W hard disk, with 4096 byte sectors
>>(both "physical" and "logical"). There are additional limitations ATM, it
>> will only mount 1
>>"disk" (partition), which must be a "primary" (defined in the MBR) and
>> reside entirely
>>within the first 64 Gigabytes of the support. It does not support an "int
>> 13" (BIOS) interface
>>either, and even the DOS functions are crippled (no IOCTL calls
>> supported...)
>>
>>None of these limits are fundamental, of course, the reason they exist was
>> to hack a
>>functional, testable, driver for my external IOMEGA disk enclosure as
>> quickly as possible.
>>Once searching the web had got me a copy of okdish ASPI documents and SDK
>> (Adaptec),
>>it was not hard to achieve this goal in 2 or 3 days' work. I do not think I
>> deserve praise ;=)
>>
>>Adding full 32-bit sector numbering (instead of 24 bits now) allowing 16
>> tebibyte disks
>>is easy and a priority. But the rest - enhanced DOS driver functions,
>> multiple partitions
>>including secondaries, mixed sector sizes, int 13 BIOS...will have  to
>> wait, may be forever
>>- unless there is going to be strong demand, and then possibly against
>> retribution, i.e., not free :(
>>
>>> The idea is the following, as demonstrated for SCSI/USB/Firewire:
>>> 1) load a DOS floppy image in memory while hiding all drives
>>> (Syslinux/Grub)
>>> 2) load driver for mass storage controller (SCSIMGR$)
>>> 3) load driver for disks (ASPIDISK.SYS)
>>> 4) get access to the recognised partitions/filesystems
>>> (preferably including int13)
>>
>>IIRC someone on this list, Eric Auer possibly? opined int 13 not to be such
>> "a must".
>>I like "KISS" where possible and BTW the "minimal" driver I have now for
>> all its limitations
>>is under 1 kilobyte resident. So, being lazy does bring instant reward, too
>> !
>>
>>To be fair, the real hard work,  i.e. the USB protocol "stack" is done not
>> by this ASPIDISK thing,
>>but by USBASPI !
>>
>>--
>>Czerno
>>
>>
>>------------------------------------------------------------------------------
>>Rapidly troubleshoot problems before they affect your business. Most IT
>>organizations don't have a clear picture of how application performance
>>affects their revenue. With AppDynamics, you get 100% visibility into your
>>Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>>_______________________________________________
>>Freedos-devel mailing list
>>[email protected]
>>https://lists.sourceforge.net/lists/listinfo/freedos-devel
>>
>>
>>

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to