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 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,
> kernel, freec
> 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
units, first drive :", which wo
> 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 D
> 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 assign
> 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
Yes, I knew. Thanks. :-)
On Sat, Aug 6, 2011 at 6:51 PM, Geraldo Netto 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.
--
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 wrote:
>>> Anyone can please upload the __correct__ "HISTORY.TXT" file for the
>>> 2040 kernel release on some place where it is ea
>> 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_Branch&action=history
> <<<--- {{delete}}
I ha
> 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
Hopefully last update for a while. :-)
changes
http://fdos.svn.sourceforge.net/viewvc/fdos/trunk/source/BASE/devload/devload.asm?r1=137&r2=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 (alrea
On Aug 5, 2011 3:34 PM, "Bernd Blaauw" 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=138&r2=139
> >
> > or download
> > http://www.fdos.org/kernel/testing/devload.com
> >
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=138&r2=139
>
> or download
> http://www.fdos.org/kernel/testing/devload.com
>
> I will work on releasing 3.25 tonight or tomorrow after I get
> 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
Work in progress
see
http://fdos.svn.sourceforge.net/viewvc/fdos/trunk/source/BASE/devload/devload.asm?r1=138&r2=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 sugg
> 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
l
On Aug 4, 2011 9:13 PM, 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 change fai
On Aug 4, 2011 9:08 PM, "Bernd Blaauw" 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
>
I
> 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 5
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 scri
> 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
--
BlackBe
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=133&r2=138
Basically this adds the /Dx option w
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 sug
> 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 n
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
> 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 me
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
> 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 c
> 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
On Sun, Jul 31, 2011 at 10:58 AM, Bernd Blaauw 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 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
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
Hi again,
On Tue, Aug 2, 2011 at 8:16 PM, Rugxulo wrote:
>
> On Tue, Aug 2, 2011 at 6:48 PM, Bernd Blaauw 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 able and willing to c
Hi,
On Tue, Aug 2, 2011 at 6:48 PM, Bernd Blaauw 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.
> http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/dos/ke
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 chang
Hi,
On Tue, Aug 2, 2011 at 11:53 AM, Bernd Blaauw 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 just not fi
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 cont
> 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.
>
>
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
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
--
G
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 de
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
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.
Y
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 tempora
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 files, redirection
and pipe symbols, etc.
However I'm experiencing that the initialisation part of TDSK i
45 matches
Mail list logo
