Gui55 wrote:No, I know that. What I'm talking about is where you type "imgmount c 'image file' -ide 1m" and instead of mounting it it says "image must be on a host or local drive". This is a new bug since the project was updated to vs2015. It doesn't do this in the latest vs2008 release on github..... The latest commit that allows you to compile on vs2015 does however. If I mount the directory of the image as C with the normal mount command and type DIR, only files (including hdd images) <=2GB are found in that diectory.
Like I said, this bug is here only ever since Codeholio updated from vs2008 to 2015. Tested on both 32/64 bit builds.
So, Microsoft has decided that their runtime should emulate O_LARGEFILE in Linux? [http://linux.die.net/man/2/open]
To explain, Linux by default denies access to a process if the file is 2GB or larger unless you use O_LARGEFILE. The C library then provides open() and open64(). If you define _FILE_OFFSET_BITS == 64 it uses a #define to map open to open64 for you. This is only done on 32-bit as far as I know, only because so many programmers used int and long for file offsets (one example that comes to mind is the source code to ARJ and the support code in it to compile on Linux). There is similar mapping for lseek/lseek64.
There is also a corresponding fopen() and fopen64() provided by GLIBC in Linux that has the same effect with fseek/fseeko depending on which version you use. You use the newer version if your code uses off_t instead of just int or long.
So the question is: if Microsoft is doing this in their library, what is the alternate form of open/fopen that removes the 2GB limit? There is nothing in their MSDN documentation about this limit or how to remove it. If they don't provide a way out, then I may have to rewrite the code to use lower-level open() and lseek() functions instead and hope that's not where the 2GB limit is imposed. My past cynical experience with Microsoft "helpful" changes like that is that they probably didn't provide a way for fopen() to go past 2GB and they probably don't care, but we'll see.
edit: these comments are based on my observation that at a good portion of the disk image code uses fopen/fseek/fread functions.
edit: I see some report on what they changed, but I don't see anything about fopen() and readdir() unable to see 2GB or larger files: http://blogs.msdn.com/b/vcblog/archive/2014/0 … io-14-ctp1.aspx
DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.