I'd have to check the sources I have here for several dos versions,
but having share only check be performed upon open/close of files
makes perfect sense to me, In fact, couldn't there be a flag raised
upon share install, then unset when share is removed, thereby making
the check as simple
I'm not sure if this is the right place for it, but I've noticed
recently, that pkunzip and unzip treat files with directory
information differently on freedos.
I'm using the 1.0 kernel releases (tried upgrading to 1.1, but had
some issues, so had to reinstall 1.0)
But, what happens is this:
On Dec 16, 2008, at 9:08 AM, Alain M. wrote:
> From your description, it looks like there is a bug in pkzip. That
> is a
> comercial product, so the answer is simple: BUY one and ask for
> support...
>
> As to unzip, it is freeware, well supported, and in fact it is a
> port of
> the Linux
On Jan 14, 2012, at 5:26 PM, Eric Auer wrote:
> are simply too small to be bootable anyway. I wonder if you should be
> able to boot from nonstandard sector sizes at all - for example a CD-
> ROM does not even have a FAT filesystem, so why would you boot from a
> (raw!) CD-ROM then?
Booting from
The only problem with virtual box is that it isn't accessible. Any folks
using screen readers are likely to need dosemu instead of virtual box. It
may work under orca, but I've not tested that here.
Just a point of interest for those who need/want to know.
---
I don't know if it's still available, but pts dos has source that you're
allowed to use in your projects. I haven't looked at it recently, so I
don't remember what license it was released under, (if any) but I do
recall that as long as you held a license for pts dos, you were free to
use the s
On 11/29/2016 3:32 PM, H. Peter Anvin wrote:
> On 11/24/16 00:59, Mateusz Viste wrote:
>> Hi,
>>
>> Your problem is related to the fact that your "nasm" command doesn't call
>> nasm.exe directly. Instead, it calls a batch file named nasm.bat which
>> has been placed in your %PATH% by the FDNPKG i
