FYI, D.COM is HotDIR 2.03, originally named HDIR.COM, which you can learn with the /? parameter. There is a free program named MaxDIR, also for DOS, with more options and more colors, in case you thought more were needed.

Please find attached my port for Win32, both C++ source and binary (45k). This implementation fully utilizes Unicode and displays Long File Names using column widths determined by the width of the console window. The project/solution should build nicely in Visual Studio 2012 (Express) and up.

Nice work. I have been using the DOS version in the past few years. Now have the habit of typing D on every systems command prompt, even if there is no D installed at all...
I am wondering, would things look more orderly if sorted from top to bottom and then from left to right? Like in windows explorer list view.

I guess this is typically one of those little tools that you can tweak indefinitely.. 😀 Here's a small update to allow sorting by column.

Awesome, thanks!
....Unfortunately it does not work on windows XP, so I cannot try it now. Maybe I should compile the source with something older, like MSVC 2005?

Hmm, no idea what's the problem there, sorry. 😕

Some possible reasons it won't work: XP is not SP2 or later, appropriate runtime DLLs are not installed.

ripsaw8080 wrote:

Some possible reasons it won't work: XP is not SP2 or later, appropriate runtime DLLs are not installed.

No, it is patched up to today. XP says D.exe is not a proper WIN32 executable.
MSVC2005 won't compile the source, as it trips over the vector related syntax.

Apparently, you have to set the correct target 'Platform Toolset'... The attached executable runs on WinXP (that is, if you have installed Visual C++ Redistributable for Visual Studio 2012, http://www.microsoft.com/en-us/download/detai … s.aspx?id=30679).

That fixed it, your D program works on windows XP now. Thanks again!

I always used ZDir:

http://tipovers.org/zdir/

It is also most likely incompatible (and lacks source) but might give you some more ideas of features to implement in this new program...

Ok, please disregard the deleted post, it was never there....... Didn't check to see if there were any downloads or not, but came across some nasty bugs I had missed while porting to windows. So, the "final" DOS version is nothing of the sort. ((ps... by nasty, I meant stupid illogical paths I put into the code, nothing harmful, just embarrassing.))

Got my windows port up and running though 😀 Seems to work just great. I'm afraid the code looks nothing like rcblanke's code. I'm old school, I guess, most of what he was doing was beyond me. Anyways, Windows port entering beta now. The problem is that I'm working with VS2008, and it doesn't have the "Target Platform" option that 2012 does. I "think" I made it operable on XP and later, but I'm not sure. Don't have a handy XP install to check. I also think I've eliminated the need for the runtime libraries (but again, I'm not 100% sure.) From what I've been reading, I am "not" going to try it on my Win98 system. I've been tempted to try and get VS2005 so I can eventually write a LFN version for Win9x. Though, I have to get this one up to LFN support first. For now, it supports variable display sizes from 13 columns to 197 (largest I was willing to have my eyes suffer through on my monitor,) and rows from 6 to 70 (ish, limit due to same reason.) Still in the process of cleaning up code after conversion.

What it includes. Everything HotDir had, with more colors. The output is completely re-direct able, and it even detects it and automatically turns browsing mode completely off for you (actually, I sort of HAD to put the detection code in, weird things happened if I didn't.) Unless you use ANSI codes, though, the text will be mono color. With ANSI codes, it will be hard to read without an ANSI enabled reader. I've changed it from selecting number of columns to selecting verbosity (going to be tweaking that later,) after adding in code for other than 80/40 display modes. I added in the ability to separate out the directories (display first, last, or not display at all.) Purely because I like having them separated. And the main part of the D.EXE available near the beginning of this thread that I liked, "browsing" mode. If the directory is more than a single screen it goes into browsing mode, allowing backward and forward scrolling. It uses memory dynamically, so it only reserves what it needs to store and sort a given directory. Experimenting, I ended up with an upper limit at 52 million entries.... At which point I stopped, I really doubt anyone will have directories with more than 50 million entries. The largest directory I've actually tried with it is 2538 files & directories (Windows\System32) I haven't looked for anything bigger. It doesn't even hesitate 😀

I tried everything I could think of to break this latest release. But my imagination isn't the best. Please let me know if you can find anything wrong with it. Right now, I'm cleaning the string functions out. It turns out that 90% of the C++ string functions are hugely wasteful of time and processing. There are some cases where it is called for, but not the massive amount I was using before. Doing things manually is usually safer anyways (though a bit harder to program.) I'm also back porting a lot of the changes I've made, as they are little more than cleaned up code (and fixes.) I'm happy with the 1600 file limit of the DOS .COM file, but I'd still like to see if I can stretch it any further. After everything is streamline, comes the hard part of adding in LFN support (well hard for me anyway.) The only way I can really think of doing it is to scan the directory "before" starting to calculate column width and numbers. Then you know the largest filename and extension. I've already added in support for long volume names. I'm also looking into support for files over 4GB in size.

It never fails, as soon as I say I can't find anything wrong and post it.... A dozen problem suddenly jump up and say "ha ha, missed me!!" Well, after a couple of major revision and a bunch of minor corrections.... Another version. Sorry about that.

A partial list of the corrections.....

1) File names of 8 characters with no extension were getting truncated at 7 characters.
2) Using the wrong variable in a reference led to random illegal access crashes (that was a real pita to track down.)
3) For some reason, files of exactly 3.2 were becoming 4.0 files.... Another wrong variable used, but still can't figure out why it developed a pattern like that.
4) Stopping the list here, too many really to list. Here's the corrections.

Oh, and finally got rid of almost all the str references. Still a couple used for search purposes.) Still debating if I'm going to build manual routines or just leave them there. They are rather important, but replacing them shouldn't be that difficult either. Just like replacing the Borland only routines with first INT routines then direct memory read/write routines was absurdly easy.

p.s. I think I found the way to target specific machines. It only goes back to basic XP, but I set it to that and I'm keeping my fingers crossed. The only way to keep from having to supply DLL files is to statically link them. I hate this because it keeps them from ever being updated (though it also keeps my code from becoming obsolete,) and it greatly increases the file size. 30k to 90k just for example. I wish, it was smarter and just included the parts of the library I'm actually using 🙁 I know Borland does, and if a system that antiquated can do it, why can't a modern compiler??

Backport finished (I hope.) Again, can't find anything wrong, but as soon as I say that.....

Back port wasn't really that difficult, I just took the some of the code cleanup and put it in the old. Did manage to break a couple of things doing that, though. Fixed them up (I think.) I also liked my new time date method, but it didn't port well 🙁 Putting the old one back - later, (will be v2.5.0 assuming I don't have other things to fix crop up,) right now, I have a rather clunky fix in place (new sort code,) but I also now know why DOS measures file time in 2 second intervals. Going to take a programming break for a bit (starting to dream in code again.) I'm hoping people will be willing to test this for me and find the bugs I missed. Feel free to pm me, or just post I guess, any you find. When I'm satisfied that I can't find any more bugs (and I might try to streamline things a bit more, add in detection if file list exceeds the counters for example.) I'll move on to the next stages.

If everything comes out ok, the next stage is to get the 32-bit code old OS friendly (Win95,98) if I can. Then see if I can use the 64-bit addressing without going full out 64-bit (will need someone with a 32-bit system to test that part out.) Like the idea of being able to get rid of my rather clunky 32bit size + overflow conversion mess. Couldn't think of any way around that though. I'm hoping that since a 16-bit system can perform 32-bit math, a 32-bit system will be able to perform the 64-bit math. The final step, just for completeness sake, will be to do a full on 64-bit port. <edit> p.s. - Also plan to put LFN support in there if I can work out an acceptable way to figure the column width's and such. Also, putting in mention to the originator's and such (rewrote all of it, but they were the inspiration.)

Again, the DOS version comes in 2 flavors. The .com version that is limited to 1600ish entries in a directory, but is smaller, and should be faster. And the .exe version, which is limited to 2800ish entries. Personally, I rename the D.exe to E.exe, and if D comes up with "Too Many Files" I just use E instead. Not likely to ever happen, but....

The Windows version, is actually limited to 65,535 files & 65,535 Directories (because the counters for each are 16-bit.) I intend to put in a means to detect overflow eventually, just don't see a real need right now (still in beta.) Nothing bad happens, the counters just wrap around and you end up with fewer entries being displayed than are actually there (65,536 get left out.) Really though, if you have that many files in a directory, be prepared to wait as the computer reads/sorts them all. I was expecting not to have to worry about it, as I was expecting to have a memory allocation limit. However, all my testing puts that limit at extremely high values. Sure, I could re-code and actually set that high limit, but is there really a need to try and sort 50 million file/directory entries?

Oh, I love you, I must try this. I *live* in LIST on any system where it works.

Came here to note that the source code for LIST v6.0 was released as public domain, but cannot find my copy nor where I got it.

ok, this is fantastic 😀 hotdir was like my must have dos program cause it made looking through the contents of anything just so nice and easy to deal with! thanks 😀

ooh, found a bug, altho not sure if anyone will care 😀 in the win358 version, /c makes it do nothing at all. the system pauses then gives a new command prompt 😜

so you get it lookin like this:

C:\d /c

C:\

(doesnt matter if you do "d/c" or "d /c" both output the same result)