OK, got libpng to compile now, that. The problem with zlib is the lib builds fine, but when I try to build a dll, I get the error "..\..\masmx86\match686.obj not found"

libpng seemed to build the zlib just fine, but they have the wrong names zlib1d.dll and zlib1d.lib, I'm loathe to rename them.

OK, now I feel like an idiot. I kept building debug versions of libpng (and thus debug versions of zlib.) Change them all to release versions and they produce zlib.lib and libpng.lib. Though the dll files still have extra... zlib1.dll instead of zlib.dll and libpng16.dll instead of libpng.dll. Will I need the zlib.dll and libpng.dll from somewhere else??

Never mind.... Just tested it. Nothing but the libpng16.dll and zlib1.dll files in place. Screenshot works jut fine 😀 Copy command works just like the MSDOS counterpart (preserving date, etc...) Now trying the dearj without the environment variable 😀..... That works just great too. So, a SVN build altered to preserve time/date stamps (including the copy command,) and can take screenshots and stuff without issue 😀 Thanks for everyone's help. Now.... is someone willing to build a diff file for me? I have no idea how to do it. It would come in handy if I want to incorporate the changes for future SVN builds.

Oh... and the "move" function (in DOSBox you use rename, just change the path,) preserved the time/date stamp without issue already. It was only when a "new" file was created (through copy or some similar function,) that the time/date was changed.

Posted diff to the patch thread. Thanks 😀

FeedingDragon wrote:

and the "move" function (in DOSBox you use rename, just change the path,)

DOSBox's REN shell command doesn't handle wildcards, so that's probably why Daum SVN includes the MOVE.EXE on the internal Z: drive.

FeedingDragon: maybe you can update the Wiki instructions with the stuff that you really couldn't figure out by following it.
From your "newbie" experience others could learn 😉

ripsaw8080 wrote:

FeedingDragon wrote:

and the "move" function (in DOSBox you use rename, just change the path,)

DOSBox's REN shell command doesn't handle wildcards, so that's probably why Daum SVN includes the MOVE.EXE on the internal Z: drive.

I'm wondering how hard it would be to create a CMD_MOVE section to shell_cmds.cpp. It would basically be CMD_COPY with a delete aspect built in. Go through the file(s) in the same manner as the CMD_COPY file (removing the concatenation aspect, actually error out if the +'s are there.) Each file would first be passed to the CMD_COPY function, and if it returns a "successful" process, pass it to the CMD_DELETE, then do the next file, etc... Would have to add in a "return" value for CMD_COPY though. So that the CMD_MOVE process would know if a copy faiiled (and not delete the original.) Don't think I could program that myself though. I only understood the CMD_COPY function just barely enough to know where to put the GetFileDate and SetFileDate calls, and to set it up to only do so if the files weren't being concatenated. Project for someone else, I guess. Lets see, change the "void DOS_Shell::CMD_COPY (char * args)" to "bool DOS_Shell::CMD_Copy (char *args)" (in both the function itself and the declaration, of course.) Shouldn't hurt any other aspect of the code, just because a function returns a value, it doesn't follow that you have to read that value. Then have to add in all the return values (TRUE or FALSE, FALSE meaning faiure of course.) Not so difficult, look for all the places that include "WriteOut (MSG_<whatever>,) lines and have the all followed by return (TRUE/FALSE) lines Depending on what the "MSG" was of course. Would be better to do it one file at a time, though, to more closely match original functionality of the DOS command.

Argh.... I feel another sleep-depriving project coming on 🙁 Wonder if I could just copy the move.exe (move.com?) from the Daum build to my DOS directory (I put it in my path for things like XCopy, D.com, List.com, etc...) and use that.

Dominus wrote:

FeedingDragon: maybe you can update the Wiki instructions with the stuff that you really couldn't figure out by following it.
From your "newbie" experience others could learn 😉

I might add something, if I can figure out how to do it (write it out so that others can understand.) My thought process are considered somewhat non-standard, I'm told. Not tonight though, I'm already up well beyond my bed time... ACK!! it's 5:30 am... I hate it when a project really grabs me 🙁

Ideally you would use REN when moving on the same drive, COPY and DELETE when moving to a different drive. REN is relatively fast, that's why you'd want to use it where possible.

Yes, you can copy Daum's collection of utility programs out of the Z: drive and use them in other builds.

ripsaw8080 wrote:

Ideally you would use REN when moving on the same drive, COPY and DELETE when moving to a different drive. REN is relatively fast, that's why you'd want to use it where possible.

Yes, you can copy Daum's collection of utility programs out of the Z: drive and use them in other builds.

I had actually thought about that while I was waking up. In MSDOS, if you are moving on the same drive, all it does is rewrite the directory entries, no actual copies are made. So a CMD_MOVE function would check first to see if the target was on the same drive, then either call the CMD_RENAME function or call the CMD_COPY followed by the CMD_DELETE functions. It seems to me that that would be the easiest way to do it. Of course there would be the validity checks, are you trying to move something to the same place, is the target valid, etc... Are you moving a directory, if so, add in the CMD_RMDIR command (if you moved to another drive, I think the CMD_RENAME functions already handles directories.) Is the directory nested (does it have sub directories as well.)

Because CMD_RENAME doesn't handle wildcards, you would also have to break it down into single file calls (if wildcards were used.) Alternately, and this will save processing time as well, you could just copy the appropriate code from the other functions over. The problem with using the functions in place is that a lot of the validity checks will be duplicated. CMD_MOVE has to check if it's the same drive or not, is the command legal, etc... Then if you pass a file off to CMD_RENAME or CMD_COPY then CMD_DELETE, all 3 will be doing what you already did all over again. So DOSBox will be checking if the command is valid 2 or 3 times for every file. Easier for the programmer, harder on the end user's system. Personally, I'd say just copy the code over, then edit as appropriate.

So, as I see it: Check if the command is even valid (exit with appropriate message if not,) Check if it's to the same drive (skip RENAME section if its not,) RENAME section - Using the code from CMD_COPY build a loop for the files (for when wild cards are used,) in that loop use the code from CMD_RENAME to move them (the code already handles directories & sub-directories,) all successful? End process. COPY/DELETE section (Skip point) - Now we have to get a little more creative. The copy command doesn't handle directories. It already has a loop in place for wildcards though. Strip out the part about concatenating files (would be ignored anyway as the validity check should have already eliminated the possibility.) Now, is the source a directory? If so, we have to build a directory structure at the destination, build a list the directory and all sub-directories from the lowest to the highest. Then the first loop with the directories, inside this loop is a loop for the files themselves - use the same loop from CMD_COPY with the file name *.* Adding in the CMD_DELETE code if the "copy" is successful (if the copy fails, send an error message and exit the MOVE function.) Each time the second loop finishes successfully, use the code from CMD_RMDIR to remove that directory (if there was a failure, again send a message and exit.) All successful. Send a success message and exit. Now, you can also remove the file name echo code of the CMD_COPY function, Move in MSDOS echoes nothing.

Not really all that easy. Quit a bit of work there.