Derek_Stewart wrote:If a file is saved in Q-Emulator to a Windows mapped Folder. I asdume a QDOS header is attached to the file.

Can this file be read on a non-emulator QL?

Is there a command in Q-Emulator not to add a QDOS header?

The header is ONLY added to the file if required (ie normally an executable file). BASIC files, and code files are easily transported between emulators and QLs. Q-emulator does not offer an option as such not to add a QDOS header (although you can use SBYTES instead of SEXEC) - as the executable file would then no longer be useable.

That is the same issue with any emulators which try to store QL files on native WIndows / Mac folders - what do you do with the QDOS header when it is needed? Some emulators create a second file which contains the header, but that does not help you get the file onto a normal QL.

Q-emulator does of course recognise if you are copying an executable file to a QL formatted disk, disk image, qxl.win file, microdrive image or zip file and write it with the normal file header so anything else can load in from this.

Following information on QemuLator native windoze hard disk file headers added to QL executables in case someone wants to write a routine to 'strip' these added bytes once the program is transferred to another file system such as QL (info from QemuLator manual Appendix 2):

Q-emuLator for Windows stores part of the header at the beginning of files. The header is presentonly when it is useful, ie. only if it contains non-default information.The header, which can be 30 or 44 bytes pre-pended, has the following format:

The first 18 bytes are there to detect whether the header is present (ID string).The headers Q-emuLator supports can be 30 bytes or 44 bytes long (the value of thecorresponding byte at offset 19 is either 15 or 22). In the first case, there are 10 bytes with the valuespresent in bytes 4 to 13 of the 64 bytes QDOS header. In the second case the same piece ofinformation is followed by 14 bytes containing a microdrive sector header, useful for emulatingmicrodrive protection schemes. Additional header information (file length, name, dates) is obtaineddirectly from the file through the host file system.

Easiest way to strip the header is to let QemuLator do it - copy it to a non-Windoze medium such as ramdisk or QL floppy disk before zipping it up and transferring it, for example, rather than zipping it up in Windoze. QemuLator automatically removes the header when it spots that the file is going to QL format media such as ramdisk or floppy disk.

Ralf R. wrote:I can't understand this problem. In S_Edit, I set SV_DDLST to "" to not let TK2 use its default directory. The only way to do so, to examine, if a file name really exists and to prevent TK2 to rush its default directory in front of a filename. So, things like "win1_flp2_test_asm" are not possible. That's the most bad behavier of TK2 (in my opinion).

At least, if the filename isn't found, I set SV_DDLST to its original value and try again. If that isn't found, it is a new file.

I assume you clear out the pointer to the default data directory (sys_datd at $B0), not SV_DDLST as clearing out the latter means the system won't find any directory device anymore...Note that the IO.OPEN trap doesn't recognise the default directories so it's up to the application program to look for them, and doing an IO.OPEN with D3=4 (directory) is the easiest way to check if a particular device exists. Of course, one could scan SV_DDLST for device names to avoid prepending the default directory in your particular example (when flp2_ is not mapped to a physical device or has no floppy in it an OPEN_DIR would fail and win1_ would be prepended which is probably not desired). But this would fail with simple devices like ser (which would be found with IO.OPEN as they ignore the type key in D3) and IMHO it's a bridge too far for an application program like QED to dive into system tables.