Op 9-8-2011 3:06, Kenneth J. Davis schreef:
I finally had a chance to do some testing.
I believe it is a VirtualBox bug.
VirtualPC and VirtualBox seem to have their issues. Other emulators show
their own explicit nuisances as well ofcourse, but that seems to be more
limited.
I tried with
On Fri, Aug 5, 2011 at 7:45 AM, Kenneth J. Davis jere...@fdos.org wrote:
Work in progress
...
As a side note, on my netbook using similar VirtualBox setup I have
found that I can only use devload without any memory managers -
something related to no UMBs so I need to see if it is a devload,
This version still has a known error with regard to CDS (drive
assignment) - all drive letters are assigned successively (ie E: F:
G:), if LASTDRIVE is reached it will gracefully handle that, but if
there is a hole between used drive letters but it is not big enough
for all units then it will
I think your only two choices are to abort, or to try skipping over the
first hole you find and try to find another one with enough consecutive
units.
Ah, true, finding enough consecutive free CDS entries elsewhere would work
too. However, as I stated in the other mail, I think that assigning
Ah, true, finding enough consecutive free CDS entries elsewhere
would work too. However, as I stated in the other mail, I think
that assigning non-consecutive entries is possible too - and would
probably do for most drivers.
DOS only tells the driver what the first drive number is, and DOS
If the driver status
information gets displayed somehow, or there is some sort of interaction
between the drives in the software, though, it would always assume things
were consecutive.
Yes. I think I've seen drivers which display messages like Installed
num units, first drive letter:, which
This version still has a known error with regard to CDS (drive
assignment) - all drive letters are assigned successively (ie E: F:
G:), if LASTDRIVE is reached it will gracefully handle that, but if
there is a hole between used drive letters but it is not big enough
for all units then it will
Anyone can please upload the __correct__ HISTORY.TXT file for the
2040 kernel release on some place where it is easily discoverable ?
Both SF and fdos.org ?
http://sourceforge.net/apps/mediawiki/freedos/index.php?title=Unstable_Kernel_Branchaction=history
--- {{delete}}
I have deleted
Hallo!
Mceric == Eric (Auer) :P
Geraldo Netto
Non dvcor, dvco = Sapere Aude
São Paulo, Brasil, -3gmt
site: http://exdev.sf.net/
On 6 August 2011 20:40, Jim Hall jh...@freedos.org wrote:
Anyone can please upload the __correct__ HISTORY.TXT file for the
2040 kernel release on some place where
Yes, I knew. Thanks. :-)
On Sat, Aug 6, 2011 at 6:51 PM, Geraldo Netto geraldone...@gmail.com wrote:
Hallo!
Mceric == Eric (Auer) :P
I have deleted the old Unstable_Kernel_Branch entry from our wiki.
File history showed it was uploaded/owned by wiki user Mceric.
I'm not clear what the 2nd bug is - but I think i get what u are
saying, I don't handle case of initial drive letter already beyond
available last drive, ie lastdrive=y and trying to use z may use
invalid cds entry.
Yes. Basically, whenever the offset that you initially use is beyond the
last
Work in progress
see
http://fdos.svn.sourceforge.net/viewvc/fdos/trunk/source/BASE/devload/devload.asm?r1=138r2=139
or download
http://www.fdos.org/kernel/testing/devload.com
I will work on releasing 3.25 tonight or tomorrow after I get feedback
on the error levels to use and hopefully some
hopefully some suggestions of multi device drivers to test with.
When I wanted to know how to load multi-header device drivers, I created
various drivers with NASM and tested them with various implementations. (I
might still have these examples around somewhere at home. Unfortunately, I
won't be
Op 5-8-2011 13:45, Kenneth J. Davis schreef:
Work in progress
see
http://fdos.svn.sourceforge.net/viewvc/fdos/trunk/source/BASE/devload/devload.asm?r1=138r2=139
or download
http://www.fdos.org/kernel/testing/devload.com
I will work on releasing 3.25 tonight or tomorrow after I get feedback
On Aug 5, 2011 3:34 PM, Bernd Blaauw bbla...@home.nl wrote:
Op 5-8-2011 13:45, Kenneth J. Davis schreef:
Work in progress
see
http://fdos.svn.sourceforge.net/viewvc/fdos/trunk/source/BASE/devload/devload.asm?r1=138r2=139
or download
http://www.fdos.org/kernel/testing/devload.com
Hopefully last update for a while. :-)
changes
http://fdos.svn.sourceforge.net/viewvc/fdos/trunk/source/BASE/devload/devload.asm?r1=137r2=141
download
http://www.fdos.org/kernel/testing/devload-3.25.zip
This fixes a few issues from previous 3.24 release:
- if initial CDS entry is invalid
Please try http://www.fdos.org/kernel/testing/devload-3.23.zip
and let me know if you experience any issues with it.
I have done limited testing with it using shsucdx and tdsk and it
seems to fix the issue. Note that if you install shsucdx then tdsk
then uninstall shsucdx thus creating a
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/history.txt
COOL :-)
Eric wrote:
Thank you, that is more search engine friendly than having to browse
the www CVS/SVN page on sourceforge. However, you still need to use
a search engine to find the history.txt, maybe we
Op 4-8-2011 10:51, c...@bttr-software.de schreef:
However, user-settable drive assignments would be interesting, ie,
providing command line options to specify which drives are tried. I think
SHSUCDX implements some such options. There's no technical reason DEVLOAD
couldn't.)
Hehe, feature
Hehe, feature creep coming up :).
as usual.
* LASTDRIVE= modification on the fly.
CDS resizing isn't trivial though. It is in fact quite complicated, and
might be problematic in various environments (MSW, resident software
keeping pointers into the CDS, etc). It will also usually fragment
Op 4-8-2011 5:55, Kenneth J. Davis schreef:
Please try http://www.fdos.org/kernel/testing/devload-3.23.zip
and let me know if you experience any issues with it.
Works for me so far, at least for Tdsk, SHSUCDX and SUBST. Didn't test
MS-Client ('d have to dig up some ModBoot or Nwdsk bootdisk
I'll take this in as DEVLOAD 3.23. Your own decision if you prefer
implementing Christian Masloch's improvements and perhaps even some
additional features.
I would be inclined to answer in a most cynical fashion if you indeed did
call the bug fixes I suggested improvements (optional ones
Op 5-8-2011 2:44, c...@bttr-software.de schreef:
I would be inclined to answer in a most cynical fashion if you indeed did
call the bug fixes I suggested improvements (optional ones nevertheless)
here. I hope you didn't!
(That's not to say I'd force anyone to implement whatever I am
Please test lastest version of devload - version 3.24 available for
the time being at
http://www.fdos.org/kernel/testing/devload-3.24.zip
For changes since 3.23 see
http://fdos.svn.sourceforge.net/viewvc/fdos/trunk/source/BASE/devload/devload.asm?r1=133r2=138
Basically this adds the /Dx option
I am still not sure number of
block drives would ever not be = used CDS entries,
The related bug I reported would occur with number of block drives ==
total CDS entries too, not just .
Regards,
Christian
--
Op 5-8-2011 2:53, Kenneth J. Davis schreef:
letter used (0 based, so A=0 and Z=25, note that I only tested C: or
higher) and 255 on error.
What if the driver being loaded doesn't assign a driveletter?
DEVLOAD UIDE.SYS /D:FDCD0001
A succes for that would be 0 , but as you start with 0 any
Additionally, I had thought the later check would be
sufficient for the LASTDRIVE check, but upon review I see it was not,
so implemented explicit check if we reached last drive [currently only
tested with default lastdrive = Z].
Your change fails to fix the second bug. The check on line
On Aug 4, 2011 9:08 PM, Bernd Blaauw bbla...@home.nl wrote:
Op 5-8-2011 2:53, Kenneth J. Davis schreef:
letter used (0 based, so A=0 and Z=25, note that I only tested C: or
higher) and 255 on error.
What if the driver being loaded doesn't assign a driveletter?
DEVLOAD UIDE.SYS /D:FDCD0001
On Aug 4, 2011 9:13 PM, c...@bttr-software.de wrote:
Additionally, I had thought the later check would be
sufficient for the LASTDRIVE check, but upon review I see it was not,
so implemented explicit check if we reached last drive [currently only
tested with default lastdrive = Z].
Your
Hi Rugxulo,
thanks, noticed kernel 2040 is listed on Ibiblio now as well.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2040/
would you be able and willing to copy the kernel's changelog as
it's in
CVS/SVN right now, to above directory? DOS386 and/or Christian
Op 3-8-2011 3:58, Rugxulo schreef:
Well, I half expected you to e-mail me back already! Gosh I'm impatient. ;-)
Anyways, I went ahead and just uploaded history.txt (why not?), so there.
;-)
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/history.txt
(Note that I
On Sun, Jul 31, 2011 at 10:58 AM, Bernd Blaauw bbla...@home.nl wrote:
Op 31-7-2011 16:48, Bernd Blaauw schreef:
Op 31-7-2011 16:36, Tom Ehlert schreef:
Bernd,
assign a fix (W:) drive letter to the CD drive;
Tom
Experimented a little bit more: TDSK takes first driveletter after what
Op 2-8-2011 3:01, c...@bttr-software.de schreef:
Unrelated: the software list says that the most recent version of DEVLOAD
is 3.22, but I couldn't find that right away. Is that an error in the
software list or did I just not find it?
I'm pretty sure Jim forgot to update this when Jeremy
Hi,
On Tue, Aug 2, 2011 at 11:53 AM, Bernd Blaauw bbla...@home.nl wrote:
Op 2-8-2011 3:01, c...@bttr-software.de schreef:
Unrelated: the software list says that the most recent version of DEVLOAD
is 3.22, but I couldn't find that right away. Is that an error in the
software list or did I
Op 3-8-2011 0:26, Rugxulo schreef:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/devload/
thanks, noticed kernel 2040 is listed on Ibiblio now as well.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2040/
would you be able and willing to copy the kernel's
Hi,
On Tue, Aug 2, 2011 at 6:48 PM, Bernd Blaauw bbla...@home.nl wrote:
Op 3-8-2011 0:26, Rugxulo schreef:
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/devload/
thanks, noticed kernel 2040 is listed on Ibiblio now as well.
Hi again,
On Tue, Aug 2, 2011 at 8:16 PM, Rugxulo rugx...@gmail.com wrote:
On Tue, Aug 2, 2011 at 6:48 PM, Bernd Blaauw bbla...@home.nl wrote:
thanks, noticed kernel 2040 is listed on Ibiblio now as well.
http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/kernel/2040/
would you be
Just for the record, I think the problem is that DEVLOAD only looks for
block devices and will overwrite existing CDS entries if there is no
associated block device. Which is the wrong thing to do.
Regards,
Christian
--
Op 1-8-2011 15:29, c...@bttr-software.de schreef:
Just for the record, I think the problem is that DEVLOAD only looks for
block devices and will overwrite existing CDS entries if there is no
associated block device. Which is the wrong thing to do.
I hope there's a remedy to this, if this is
I hope there's a remedy to this, if this is the case.
Yes; patch DEVLOAD (or get someone to do it).
I'd have to find other .SYS block device
drivers to see how they behave under DEVLOAD, and other device driver
loaders like Creative's CTLOAD and whichever program it was that QEMM had.
Bernd,
assign a fix (W:) drive letter to the CD drive;
Tom
am 31. Juli 2011 um 14:45 schrieben Sie:
I'm experimenting a bit with TDSK as I can see use for a ramdisk in
situations with read-only media and no memory drivers. Thus a small
conventional memory ramdisk needed for tiny temporary
Op 31-7-2011 16:36, Tom Ehlert schreef:
Bernd,
assign a fix (W:) drive letter to the CD drive;
Tom
or load TDSK before loading CD drivers, etc.
SRDISK respects driveletters, as do RDISK, SHSURDRV, XMSDSK etc.
As both SRDISK and TDSK are GPL it might be possible to copy some init code.
Your
Op 31-7-2011 16:48, Bernd Blaauw schreef:
Op 31-7-2011 16:36, Tom Ehlert schreef:
Bernd,
assign a fix (W:) drive letter to the CD drive;
Tom
Experimented a little bit more: TDSK takes first driveletter after what
seems to be last block device.
Having harddisk (C:), then CDROM (D:) then
Op 31-7-2011 16:58, Bernd Blaauw schreef:
Op 31-7-2011 16:48, Bernd Blaauw schreef:
Op 31-7-2011 16:36, Tom Ehlert schreef:
Bernd,
assign a fix (W:) drive letter to the CD drive;
Now I'll be done talking to myself..
Issue solved: SHSUFDRV does the trick as it installs as block device,
44 matches
Mail list logo
