Running games from CD

I was just making a portfolio CD with some of my Blitz game projects on. Aerial Antics, Market Value, Mashup, Fun Racer and Blox.

THe CD autoboots and Cygnus helped out with a little tool that fixes the windows path bug so I could run games fine via the HTML front end.

Here's the problem. Everything works as expected on the HD, Until I burn a CD with it on, then they all MAV. When I drag the same files to the HD (still read only) they all work again.

Anyone know how to get around this problem? Seems to be something to do with running off the CD.

Got an interview for a TV job tomorrow, and this one thing is getting in the way of success.

Perhaps they are trying to create a temp file for some reason and are unable to do this on the CD. Such as extracting media etc...

You could run one of the sysinternals file/disk tools to see what type of file/disk access is going on.

http://www.sysinternals.com/Utilities/Filemon.html

I believe blitz creates temp files before loading into memory. it could also be a path problem. Try stating a full path for the media resources. Are you using any physics libs? Or user libs?

I don't know how BMax does this (yet), but about .bb I can think of one reason.
Did you use "ReadFile" or "OpenFile" to open external files. That last one will result into returning a 0, since OpenFile can NOT be used from a read-only environment. (That was something I discovered with my file-encryptor in "The Fairy Tale").

>Did you use "ReadFile" or "OpenFile" to open external
>files. That last one will result into returning a 0, since
>OpenFile can NOT be used from a read-only environment.
>(That was something I discovered with my file-encryptor
>in "The Fairy Tale").

Would you mind adding that to 'comments' on the official docs?

http://www.blitzbasic.com/b3ddocs/command.php?name=OpenFile&ref=2d_cat

and

http://www.blitzbasic.com/b3ddocs/command.php?name=ReadFile&ref=2d_cat


Andy

Oh, you guys didn't know that.
Okay, I'll add it to the docs.


====
I've added it to the "OpenFile" command. I don't know if it's needed that I put it into the "ReadFile" command as well, since ReadFile can be read from a read-only environment.

I've emailed Evak about the issue- I know Blitz exes will need to be run off the drive- all of my programs use readfile to access INIs- and this is where the problem lies.

Evak, I will write some code to copy the projects into a temp location on the HDD before running-then remove them after running. It will be easy to incorporate into the small piece of code I wrote to help with the path issues, but it might be messy- since when files are copied off the CD, theyre set to read only. *sigh*. Might mean some DOS batches >.<;;

The other option, if you dont need them to be interactive- is to just record high quality videos.

I have a question too- Any idea how to remove a files Read Only attribute without chucking up a DOS box? :)

I've managed to do this with Moleboxed .exe files.

heh. that wont work- The racer wont run if its totally moleboxed either (i think)- so it'll have the same problem. That was a while ago, might be worth a shot!

write your own copy file function, here's a delphi example

procedure ccCopyFile(const FileName, DestName: TFileName); //JB
var
  CopyBuffer: Pointer; { buffer for copying }
  BytesCopied: Longint;
  Source, Dest: Integer; { handles }
  Destination: TFileName; { holder for expanded destination name }
const
  ChunkSize: Longint = 8192; { copy in 8K chunks }
begin
  //NOTE (JB) : The New File has not got any attributes set
  //so it is safe to use this to copy from CDs as the New File will not be Read-Only
  //originally AH's from fmxUtils

  Destination := ExpandFileName(DestName); { expand the destination path }
  if ccHasAttr(Destination, faDirectory) then { if destination is a directory... }
    Destination := Destination + '\' + ExtractFileName(FileName); { ...clone file name }
  GetMem(CopyBuffer, ChunkSize); { allocate the buffer }
  try
    Source := FileOpen(FileName, fmShareDenyWrite); { open source file }
    if Source < 0 then raise EFOpenError.CreateFmt(SFOpenError, [FileName]);
    try
      Dest := FileCreate(Destination); { create output file; overwrite existing }
      if Dest < 0 then raise EFCreateError.CreateFmt(SFCreateError, [Destination]);
      try
        repeat
          BytesCopied := FileRead(Source, CopyBuffer^, ChunkSize); { read chunk }
          if BytesCopied > 0 then { if we read anything... }
            FileWrite(Dest, CopyBuffer^, BytesCopied); { ...write chunk }
        until BytesCopied < ChunkSize; { until we run out of chunks }
      finally
        FileClose(Dest); { close the destination file }
      end;
    finally
      FileClose(Source); { close the source file }
    end;
  finally
    FreeMem(CopyBuffer, ChunkSize); { free the buffer }
  end;
end;

Or try this, it's in user32.dll [edit] no it's kernal32.dll actually:

The SetFileAttributes function sets a file's attributes. 

BOOL SetFileAttributes(

    LPCTSTR  lpFileName,	// address of filename 
    DWORD  dwFileAttributes 	// address of attributes to set 
   );	
Parameters

lpFileName

Points to a string that specifies the name of the file whose attributes are to be set. 
Windows 95: This string must not exceed MAX_PATH characters.
Windows NT: There is a default string size limit for paths of MAX_PATH characters. This limit is related to how the SetFileAttributes function parses paths. An application can transcend this limit and send in paths longer than MAX_PATH characters by calling the wide (W) version of SetFileAttributes and prepending "\\?" to the path. The "\\?" tells the function to turn off path parsing; it lets paths longer than MAX_PATH be used with SetFileAttributesW. This also works with UNC names. The "\\?" is ignored as part of the path. For example, "\\?\C:\myworld\private" is seen as "
C:\myworld\private", and "\\?\UNC\bill_g_1\hotstuff\coolapps" is seen as "\\bill_g_1\hotstuff\coolapps".

dwFileAttributes

Specifies the file attributes to set for the file. This parameter can be a combination of the following values. However, all other values override FILE_ATTRIBUTE_NORMAL. 

Value	Meaning
FILE_ATTRIBUTE_ARCHIVE	The file is an archive file. Applications use this value to mark files for backup or removal.
FILE_ATTRIBUTE_NORMAL	The file has no other attributes set. This value is valid only if used alone.
FILE_ATTRIBUTE_HIDDEN	The file is hidden. It is not included in an ordinary directory listing.
FILE_ATTRIBUTE_READONLY	The file is read-only. Applications can read the file but cannot write to it or delete it.
FILE_ATTRIBUTE_SYSTEM	The file is part of the operating system or is used exclusively by it.
FILE_ATTRIBUTE_TEMPORARY	The file is being used for temporary storage. File systems attempt to keep all of the data in memory for quicker access rather than flushing the data back to mass storage. A temporary file should be deleted by the application as soon as it is no longer needed.
Windows 95 only: FILE_ATTRIBUTE_ATOMIC_WRITE	Reserved for future use; do not specify.
Windows 95 only: FILE_ATTRIBUTE_XACTION_WRITE	Reserved for future use; do not specify.
Return Value

If the function succeeds, the return value is TRUE.
If the function fails, the return value is FALSE. To get extended error information, call GetLastError. 

Remarks

You cannot use the SetFileAttribute function to set a file's compression state. Setting FILE_ATTRIBUTE_COMPRESSED in the dwFileAttributes parameter does nothing. Use the DeviceIoControl function and the FSCTL_SET_COMPRESSION operation to set a file's compression state.

How about a launching a batchfile instead of the exe?

Something more or less like this if my brain remembers right.

File: LAUNCHAA.BAT
@echo off
xcopy \Cdfiles\AerialAntics\*.* %temp%\AerialAntics /S /E /C /Q /H /R <y.txt >nul
%temp%\AerialAntics\aa.exe
deltree %temp%\AerialAntics <y.txt >nul
rd %temp%\AerialAntics /s /q <y.txt >nul
exit

File: Y.TXT
y[ENTER]
y[ENTER]

Where [ENTER] is the enter key, not the literal text.

It will report one bad command or filename because deltree is removed from XP, and rd /s does not work pre-XP (to my unsure and not very certain knowledge).

problem with lauching batch files is it doesn't look very pro to have a DOS window pop up and then disappear as part of an install process, I know cos we used to do it years ago with our client/server software, then we changed to doing it in code instead. Also on some OSes, the batch file window won't go away unless you make a PIF instead.

Nah nah... the bat file brings up a dos box.

We did that first, then thought that a windowed 1x1 blitz window would be less intrusive and would hide behind the main window, it would allow us to copy the files, execute the project, then remove them after running.

Thanks LineOf7s. I missed that!

Evak, Problem will be solved this eve :)

Can't you just get the progs to install on harddrive first and then run? It's gonna run much slower on CD anyway, not to mention streaming off CDs in PCs are dodgy at the best of the times.

Can't you change the CurrentDir in Blitz? Years ago I had to write an upgrader program that ran from CD and had the same problems as Delphi was trying to make temp files on the CD. I just changed CurrentDir to c:\ as soon as the app loaded (but before any more code executed) and it was fine.

[edit] ChangeDir function in BlitzPlus.

ENAY has a point u know.

heh, thats all sorted :P its just the fact its on the CD now, i beleive.

The code i wrote changed the dir for the app no problem.

Enay- pretty much what im going to write is a tool to copy to HD, execute, Remove from HD in one swipe :)

Its not convenient to install all of the projects when they don't actually need installing- and a waste of time.

Damn- I kinda swiped this thread....

yeah, All but aerial antics worked fine in the end. Molebox plus Cygnus little tool did the trick for all of those. However we never did get Aerial Antics to work properly. Not sure what was different there compared to the others.

Fraps didn't like it either, and wouldn't initialize in game.
Interview seemed to go quite well anyway :)

And I know it doesn't. At least in BB and B3D. I know that because of my first test CD-ROMS of "The Fairy Tale" the "AUTORUN.EXE" file, which is automaticly run due to the AUTORUN.INF, blah, blah, is written in 100% Blitz, is executed directly from CD-ROM, and that program just works. Tested out completely on at least three diffrent Windows computers. It even reads a few files from the CD-ROM, all without problems. Only the game itself "FairyTale.exe" won't run, but the problems start once it's going to read the first encrypted files, and my file encryptor works with OpenFile, and there it crashes. Not one moment sooner.

Obviously i wasnt clear- I meant MY blitz exe's. I always use an INI system so therefore always use file access commands.
:)