if those are a .COM file, you can analyze the code using ms-dos DEBUG.
But alas ms-dos debug is a 16-bit program,
i don't know if ms-dos debug would work on dosbox or not.

i used to have LIST.COM (but not the source code) which is great for viewing the map files of "Caves of Thor".

Sorry, I can't help you with the source to those exact programs, but I did find some source for a similar directory displaying tool which I provided earlier. Do with it whatever you like. I believe it was originally compiled using Borland C++ 4.5 (some 16 years ago).

Thanks, that's close enough 😀 I might even be able to tweak it a bit so it looks the same. Might not be good enough of a programmer for that though. I did manage to find D.com, and there are 2 problems with what I found. One, the source didn't come in the original zip files, and 2 it was completely written in assembly language. Not sure I could get that compiled, and not sure it could be adapted to 32-bit either. Still looking for list.com.

AFAIK, Vernon D. Buerg's LIST.COM was shareware, with enhanced versions available by registration. As such, I doubt the source code was ever released. Pretty sure it's written in assembly language, too. You could purchase the enhanced versions up until 2010, when sales stopped after the author passed away.

A couple of links regarding LIST-like functionality in 64-bit Windows:

Free, looks kinda clunky: http://www.bizer.com/zblist/
Not free, fully GUI'ed: http://www.fileviewer.com/

sadly yes, mr. Buerg passed away and LIST just disappeared.
About D.COM though, is it possible to post here? looks interesting

Yeah, both are actually shareware. Found the "list.com" with source code on one of my CD's and also found a D.EXE with source code (which might actually be a version of the one rcblanke posted.) Looking at the list.zip file, I believe it was a "different" one, just had the same name. Sadly, the cd is one of the first ones I burned, and half the files are corrupted. I got the zip list, but they won't extract. File size doesn't even match. There is a zip of windows 3.1 install, list all the files from the disks, but the file size is 286k. My very first coaster, that I didn't know was a coaster 🙁

As it stands, I got d130 recoded to my tastes (posting zip of source & exe below). I think I got all the bugs I created out. It's sort of a blend of my d.com and rcblanke's d.exe. Saddly, the "tiny" compile breaks it somehow. Don't know enough about programming to figure out how. It could just be DOSBox flummoxing it up. Maybe someone can look at the code and streamline things. Also maybe find some bugs I couldn't

Also, haven't started trying to compile in 32-bit mode yet. Was using Borland Turbo C DOS, since that's what it was originally written on. Can't just import it into VC2008, as it uses header files VC doesn't include. Don't know if I want to try one of the DOS mode 32-bit compilers, or try to convert to VC yet. That conversion could become extremely troublesome, or it could turn out to be really easy. Oh well, that's for another day. Bed time.

keropi wrote:

sadly yes, mr. Buerg passed away and LIST just disappeared.
About D.COM though, is it possible to post here? looks interesting

Oops, sorry. D.com and List.com zipped together (not very big either one.) For anyone that prefers it over what I put out 😀

^ thanks for posting the D stuff, it does seems a nice dir command 😀

keropi wrote:

^ thanks for posting the D stuff, it does seems a nice dir command 😀

Try the D.EXE too. Worked rather hard on it and would sort of know what people think. Had to recode rather large sections of it 🙁 It depended too much on old routines that were rather limited. Still not finished either I'm afraid. I tend to be rather modular, and there are huge sections that would work better as individual routines (IMHO.) Also makes it easier to cut and past them into other programs if you want. Also, whenever possible, I prefer to have the end code in a single file. Sure, having 5 or 6 files that each accomplish a set goal is ok, but end the end, I like to put them all together (that's just me, though.) Also, in the end, I like to put anything that only ever executes "once" and never again inside the "main" routine, right up front as much as possible. I also like to have the "main" routine up front as well, with the other routines coming after (makes it easier to find the start point when tracing the code.) I like the way he separated out the "line" and "entry" routines. They get called over and over, and having a separate routine for that just makes sense.

One thing, the DIR::DIR structure includes a rather large section (even larger after I rewrote it,) that would be better served as it's own routine. All it does is set a formalized and complete path for the DIR::DIR structure to use in building it's array. Also looking into ways of splitting the array into 2 parts - part one, all the values that are individual in nature (volume label, disk size, total space used, etc....) and part two, all the values that are specific to each file (file name, file ext, file size, etc...)

The original programmer, tried to put everything all together. He also made decisions that I'm not sure I agree with. Using direct screen prints over re-directable io prints is one. cprintf may be faster - not sure I agree with that, haven't noticed any improvement myself, but stdio (I believe it is,) can be redirected without too much issue. Plans for the future, implementing the "no pause" feature that d.com has (for redirection to text files.) Changing the print method to allow for that redirection. Better parsing of illegal characters. Ooooh, thanks, rcblanke, for providing me with such a nice distraction 😀 I'd run out of projects to work on.

OK, that's it 🙁 No more fighting with other compilers. Borland suck 🙁 the whole purpose of include & library files was code conformity. That is, *.h would contain code to use standardized tokens and commands to perform the same task in different compilers and environments. the *.h file may or may not refer to *.lib files that would contain libraries to make these tasks faster & easier, containing pre-compiled code. Only Borland it seems, said the heck with standardization, and just created whatever they wanted. No wonder it was so cheap when I bought it 🙁

Sigh.... Next step, go through all the code to use includes, commands, & tokens that are actually standardized.

FeedingDragon wrote:

Also, haven't started trying to compile in 32-bit mode yet. Was using Borland Turbo C DOS, since that's what it was originally written on. Can't just import it into VC2008, as it uses header files VC doesn't include. Don't know if I want to try one of the DOS mode 32-bit compilers, or try to convert to VC yet. That conversion could become extremely troublesome, or it could turn out to be really easy.

I actually have started on a Win32 port using Visual C++ 2012. Will post the compiled application and code when it is somewhat usable.

rcblanke wrote:

I actually have started on a Win32 port using Visual C++ 2012. Will post the compiled application and code when it is somewhat usable.

I wish you the very best of luck with that.... From what I'm seeing with VS2008 (got that one legally too,) it's pretty much going to take a complete rewrite. Of course, I'm getting very familiar with how the code works with my tweaks and such. Other than cleaning some things up, it's pretty much finished. A lot of the issues I have with it now are just my personal sense of neatness. It's invisible to the end user, but internally, for example (and the original code tended to do this too, the default directories (. & ..) would stay in the path. Which would limit the usable path length. So, if you issued the command "D ..\..\Templts\*.frm" on the C drive (for example,) the resulting path would be "C:\Work\Access\Personal\Drafts\..\..\Templts\*.frm". You would actually get a listing of all the .frm files in the C:\Work\Access\Templts directory, so you get where you're going. But when you consider that the total string length cannot be more than 81 characters (drive = 2, path maxed to 66, 8 for filename, 3 for extension, 1 for the "." and 1 for the final "\",) you can see how that might limit things a bit. That example just wasted 22 of those 81 characters.) So, I'm looking into extending that 81 somehow. The 32 bit compilers I've been looking at have extremely large maximums (256 "each" for the path, filename, AND extension, for example and 6 for the drive.) Also, when I was learning DOS (back in the day,) before 32 bit windows....(ok, I'm dating myself.) The actual maximum path length (with drive path file & extension,) was exactly 256 characters. That was the size of the buffer. Still much better than 81 though. Mainly the plan is to parse the . and .. entries "before" I start working with the MAXSIZE variables for path. If you examine the code, you'll see I took the path processing routines out of the object class. This is the main reason, it allows me more "space" to work with. Trying to add the space for extra variables, and rather large ones, was causing some rather interesting effects (in DOSBox at least.) The MYDIR.CPP file is really just a mislabeled header file anyway. It's there to define the DIR class variable contents and that all. Technically, the "sort" functions should be removed too, but I don't really see a need for that yet.

I think I have most of the bugs out. I wish there was a way to remove the need to load the entire directory into memory. But sorting becomes problematical if you do. Also the scrolling feature becomes an issue. That's one of the things I like about this model 😀 I'm looking into streamlining things a bit more. Another reason for moving the parsing utility out of the object class, was to allow me to find the broken ones before jumping completely out of the main function list (from what I'm reading, the DIR::DIR counts as a variable, and gets moved to data memory because of it's size.) I also still want to find ways to make the code more compliant. The problem is, that there are no color controls for purely text based commands outside of the ones in conio, that don't exist in any other compiler I've found (so far.) The (I'm sorry to say, rather broken,) dir.h is also another command set that's disappeared it seems. But that is something I can work on 😀 Lose the ffblk structure, but there are replacements, or I can just build one myself using common functions (that every compiler has.) Once away from Borland, I could even call it the same thing 😀

But on to the next bit. A new release is ready... Finally ready (I hope, fingers crossed,) to label it beta 😀 So without further ado, here is v1.5b 😀

how about filemanager (winfile.exe)
http://www.brydon.net/winfile/

Davros wrote:

how about filemanager (winfile.exe)
http://www.brydon.net/winfile/

The entire point is that I want something that works in DOS and in the windows DOS box. I use both rather extensively, its what I learned on originally. Right now, I'm working on D. I've converted it to something I like (for the most part, still putting in tweaks here and there.) Now I'm converting it to something that is more compatible with other compilers. After that, I'll compile a 32 bit version that will work in a DOS Box in windows. I'd much rather have something that would work in both DOS (6.2 or earlier) and in a Windows DOS box. But the more I read, the more it seems I'll need to compile it into 2 different versions. I don't want to have to load a driver like CWSDMPI(?? - I'm not sure if I have the name right on that or not,) or some such, and I'm not sure I really want a program that will throw the system into protected mode when you use it. The problem is, according to everything I've been reading, you have to do one or the other to run a 32 bit program in old DOS. What would be best is if it could be compiled into dual mode, so that it'll run in either 16 or 32 bit mode depending on the OS you are running. But cannot find any way of doing that.

Oh, and I found out more about the maximum path value. What I remember was correct, sort of. The path length on old DOS didn't really have a limit, what was limited was the "current directory" size (66 bytes,) and the input buffer (266 bytes.) So, you could get a directory list of a directory with a path length of 328 bytes (current directory 66 + input length 266 bytes - "dir " command 4 bytes.) The problem is that you couldn't do anything with what you found. At the time, though, with the sizes of drives, it was extremely unlikely that you would ever have a path length that would exceed 66 bytes. If all directory in the tree had the max of 12 characters (Name.ext, yes directories could have extensions,) + 1 for each backslash, that's 5 levels. Rarely had 4, and even then very rarely had directories with extensions. Many didn't even use all 8 characters for the name. 66 bytes were sufficient.

On a slightly different note, I discovered why the tiny (or anything smaller than a compact mode,) breaks it. This version of D uses a LOT of data space. You have to compile with a 1M data segment, 64k just isn't enough. The main issue is the DIR structure, it reserves 1250 ffblk structure entries. Each ffblk entry reserves 44 bytes, that's....(digging out calculator,) 55000 bytes, just for the ffblk section of the structure. I think you can see why 64k just isn't enough for the data block. I think D.COM sorted the listing on the fly, without loading the entire directory list into memory. Back in the day, I had programed something that did the same, but I cannot find that code, and I cannot remember how exactly I did it.

**sigh** Ok, just spent 16 hours trying to fix my code, when my code wasn't the problem.... Just found out that DOSBox can't handle floating point numbers. Since tiny mode was out anyways (for now at least,) I was using them for future compatibility, when file sizes can get over 2gig, HDD can be over a TB in size, etc.... Sitting here trying to figure out haw 980k in total bytes came out to 384k in used bytes. Tweaking my code, tweaking my code. Tracking the values, watching as 4783 + 3750 became -2832482, then adding 153 became 2, them adding 2435 became 0. That was really frustrating, let me tell you. But Win7-64 bit broke my VPC (can't get DOS to work on it.) It seems to have broken the other DOS emulators I had as well. I tell you, MS needs to.... Ok, I'm not going there 🙁.... Anyways, if you are testing D.EXE in DOSBox, be warned, the numbers at the bottom are next to meaningless. 🙁 Off to try another emulator.

Ok, got VPC2007 up and running... Lots of minor fixes in this one. Mainly the FPoint is working. Also found a bunch of bugs that did not show up in DOSBox (for me at least.) If you are running on real DOS, you might have noticed a problem with the date 😒 Got that and a lot of little other things fixed now... I hope. Still cleaning and making compatible code. Almost got dir.h completely eliminated 😀 Won't be able to get rid of conio.h color commands, will have to "convert" that later. Will also have to "convert" the 1 cursor command, just can't get around it. Still working though 😀

Well, I broke it all to pieces again. Going to have to take a break for a while, starting to dream in code 🙁 Yes, I get a little obsessive at time, I'm afraid. Couldn't find modern "dos" replacements for 3 of the functions. So, did a bit of reading and wrote them myself. Shouldn't be a problem. 3 little pieces of "extremely" simple assemble and it's ready for direct porting. Everything else is compatible now. Same command structures, same conventions, same responses (or according to everything I can find they are.) But, put in those 3 replacements and "blam" the whole thing goes right to heck 🙁 Too tired to work on it any more tonight, and I'm taking tomorrow off.

It's so interesting. Going to some of the programming forums out there. Mention that you want something to work in dos, and they practically start calling you an idiot. I do my searches first, and found many people who asked the exact same question that I was planning to ask who were told... That's been asked many times, do a search idiot. In all the responses I found, every last one of them was, do a simple search, everybody asks that. Yet, after an entire day of scrolling through answers, not a single person ever actually answered any of them, just called them idiots. I think I'd rather waste my time with trial and error.

OK, it turns out it was a simple fix. Problem is, that even though I can now compile it in another compiler, it doesn't work. Just comes up with a complex error screen. So, going to take the pieces of code from this that I like, and start a new line of attack. So, this is the last release on this version line. 1.5.6beta is final for this revision. v2.0beta will hopefully be ready for testing in a few days. Going to take a different approach with a new memory management methodology (this one is a real resource hog - even before I started messing around with it.) Right now, with all the extra features I added in, it's starting to get a little on the slow side. Well, some wouldn't call it slow... but it's not exactly smooth on the scrolling. Could probably fix that, but I have almost all the features I want in it now, and those that aren't there would be easier to add in on a complete recode anyway. I finally remembered how I handled a similar issue way back when anyway. Made notes of the method I used then (less of a memory hog,) and see how much of that I can use now, and if there are any ways to streamline even that.

So, without further delay, the final in the 1.5 line is below. (I remembered to actually attach it this time.)