I can test it a bit in windows 95 if you like. Is that DC420.zip?

gerwin wrote:

I can test it a bit in windows 95 if you like. Is that DC420.zip?

Yes, the other two are old versions I'm just leaving up in case someone doesn't want the dual version. I might re-compile those later as individuals if someone wants just the single versions (from the revised code.) But all my work is on the 4 line right now. I'd appreciate it if you could try it out. I'm hoping it's Virtual PC causing the issue. It works fine in Win7, and I cannot figure out what would cause the issues in Win95. It's fascinating watching it in the debugger too.... Printing fine, then "poof" color change for no reason, all the values look good, but wrong color 😒

Yeah, sorry to say that in a normal windows 95 installation it is like this too: Some sizes and filenames take the wrong color.
Other then that, it lists the files in the 'c:\windows' and 'c:\windows\system' folders without complaining.

gerwin wrote:

Yeah, sorry to say that in a normal windows 95 installation it is like this too: Some sizes and filenames take the wrong color.
Other then that, it lists the files in the 'c:\windows' and 'c:\windows\system' folders without complaining.

Ok, back to debugging then 😒 Going to take a nap first though.... This is one I'm finding myself stumped on.

Ok, think I have the color fixed in Win95. Had to basically go back and do what I did with the DOS version and manually set the color for every bloody character that prints.... Of course, with DOS, it makes more sense as I'm writing directly to text RAM for the color changes. But, that was the only way I could get Win95 to consistently print the correct colors. Also discovered a couple of color bleed cases and fixed those as well.

I did discover another bug, though (not major,) that I'm working on. The detection method I used to see if the output was being re-directed doesn't work right any more. Going to have to look into that, as under windows, when a program is being re-directed it uses the "target" when I get the console information. DOS gets the "screen" information, so I cannot detect a re-direct there (yet.) I'm working on it 😀

A couple of minor fixes. Had the LFN measurement system off by 1 character, so a 8 character file name was acting like a 9 etc... Also, quite by accident discovered a bug in the time calculation routine. A file with a bad time stamp could crash the program. I kept getting a "D.exe has stopped responding," message in a couple of directories. Finally tracked it down to a handful of files, all with a date stamp of 12/31/2107 (which is the last date that the DOS file system supports, btw.) Turns out that the 32 bit routines of Win7 are extremely limited. They can only go up to 01/18/2038. On Win95, it reads it as 12/31/2107, but when run on Win7 (probably Vista as well, and maybe XP,) it locks itself up on date conversion because 12/31/2107 is beyond the 32 bit (which is what VS6 programs too,) limit of 1/18/2038. Looking to upgrade my compiler to a 95 compliant one that supports 64 bit time stamps. Not sure if I have the money for it, but I'll try. I need Visual Studio .NET 2003, Visual Studio 2005 added libraries that 95 doesn't have. There is supposed to be ways to get around that, but from my research it isn't that ease. For the meantime, I put in some code to strip off the high bit of the time stamp. Been looking for a way to do that ONLY if it is on XP or above, without much luck. Will update the version number when a permanent fix is in place.

Finally getting down to the end I hope. Other than building a "formal" release package (with readme, etc...) and some minor tweaks, I think I've finally got it all worked out. Got it reading files with bad date-stamps (still going to track down what caused that on my files.) The color seems to be looking good, actually fixed a bug I didn't know about till I was building the 3 new packages above. If you had a command prompt open with a buffer larger than the window (view) size, things could get rather messy. I've fixed that I do believe. If a use wants to mess with things, they can cause it to get messy by "scrolling" the buffer during a pause point. Not sure if I'm going to worry about that or not. Anyways, the latest build of each of the versions is now on the first page. I broke it down into a DOS only, Windows only, and a Combined build (D-D431.zip D-W431.zip and D-C431.zip.) Other than them being smaller, I don't really see a need for anything other than the combined version, but to each there own.

Things left to do:
1) Write up a readme.txt file
2) Streamline some of the code (primarily the code that separates the directories if needed.)
3) Fix any bugs that crop up between now and then 😀

It's working fine on my VPC 95 now, but would still like to confirm it works on a real system. I've tested it on Win7 64-bit, VPC WinXP 32 bit (had to install it to get VS2003 up and running,) VPC Win95, VPC DOS6.22, and DOSBox.

That is good news. I will be trying it out in the days ahead. And have to remember to verify the functioning of redirect output to file.
Thanks a lot for all the effort so far.

I usually use one of these three to compile programs myself:
Windows x86: Visual Studio 2005 express or GNU GCC, then for DOS Protected mode: DJGPP.
Was not aware, or never cared enough about the fact that Visual studio 2005 broke windows 95 compatibility. It does work with windows 98 though, which is more important.

Interesting to read your take on the 4GB limit and the date limits, by the way.

gerwin wrote:

That is good news. I will be trying it out in the days ahead. And have to remember to verify the functioning of redirect output […]
Show full quote

That is good news. I will be trying it out in the days ahead. And have to remember to verify the functioning of redirect output to file.
Thanks a lot for all the effort so far.

I usually use one of these three to compile programs myself:
Windows x86: Visual Studio 2005 express or GNU GCC, then for DOS Protected mode: DJGPP.
Was not aware, or never cared enough about the fact that Visual studio 2005 broke windows 95 compatibility. It does work with windows 98 though, which is more important.

Interesting to read your take on the 4GB limit and the date limits, by the way.

First, the redirect is broken again 🙁 It was working 3 versions ago, when I was working with VS2008 and DOS only. In 2008, if you used redirection (>) the "console" would report itself with negative numbers (size -13879 or something like that,) and I just looked for that and assumed numbers of that nature meant redirected output. I then set the size to a standard 80 columns and switched off browse mode. In DOS, there isn't really a convenient way of detecting it. I'm still looking, though. I believe the entire command line is saved somewhere and I can pull that up and look for the > sign, haven't looked into it a lot just yet, trying to get everything else hammered out first. Also, the ANSI output is not working right on the Windows side (works just fine on the DOS side,) going to look at that too. It never fails.... As soon as I say, "Yay, it's almost finished," 100 little bugs pop up and start laughing at me 🙁

As for the 4GB limit, when 64-bit came out and everyone was all excited about losing the 4GB limit, it struck me as strange. Yes 4GB is the most 32 bits can address, but I was wondering what happened to the segment registers. I learned computers when they were 8 bit, and segmentation was standard. 8 bits can only address 256 bytes, so you used 2 registers for addressing (giving you 64KB.) When 16-bit systems came out, I remember being a bit disappointed that the PC line only used 4 bits for segmenting (changing 64KB to 1MB,) which is why in old DOS you have to have fancy drivers for XMS/EMS access. Anyways, I started doing some research and was shocked to discover that those segment registers are still there, they just aren't used. Intel says, yep, there they are. Microsoft says, we don't know what you're talking about, 32 bit software just cannot address past 4GB. Sorry, one of my pet peeves against Microsoft.

As for the time stamps, I don't have any particular problem with it. I wish they would have given it more room for growth, but I understand what they were thinking. In college we were shown a copy of an IBM memo stating that computers will never be viable in the home market. Also, 1MB of memory is considerably more than any computer will ever need access to. So, setting up a date system that caps out on December 31st, 2107 doesn't seem that strange (that's where the original DOS timestamp runs out.) Microsoft has changed that, though. The new timestamp stops on January 18th, 2038 if you use 32bit math for reading and converting the stamp. If you use 64 bit math it stops on December 31st, 3000. I don't have a problem with any of that. I could wish that the 32 bit math processes were more in line with old DOS, but I'm not really complaining.

In many ways, MS's method makes more sense, it is just the number of seconds that have elapsed since an arbitrary date (00:00:00 January 1st, 1970, for 32 bit math processes,) measured in universal time (it's not GMT, not sure exactly what they are basing it on.) That gives us an end date of ??:??:?? (don't know the exact hour/minute/second off hand,) January 18th 2038. The main problem is that this is the limit because the stamp is a "signed" value. So the 32 bits has a max value of 2147483647, that number could be doubled (another 68 years 17 days plus whatever hours/minutes/seconds,) by just making it an unsigned variable and getting that extra bit. Apparently, they wanted the -1 for error marker, but I'm wondering why they just don't use "0" as the error marker. On the other hand, DOS used 2 16 bit values, the first (time) was broken down into 5 bits for seconds (in multiples of 2,) 6 bits for minutes, and 5 bits for hour. Seconds ranged from 0 to 62 (0 to 31 actually, but multiplied by 2,) minutes from 0 to 63, and hours from 0 to 31. Quite a bit of waste there, as you can see. The other 16 bit value was broken down into 5 bits for day, 4 bits for month, and 7 bits for year (minus 1980.) Day ranged from 0 to 31 (only the 0 is wasted, not bad really,) month from 0 to 15 (12 - 15 wasted,) and year from 0 to 127 (1980 to 2107.) It covers every possible date in the range, but is a little wasteful.

A couple of bug fixes:
When sorting by date, the year was having high bits truncated (all but the lowest 6 bits.) So, the year (the most significant sort aspect,) was being broken up into 64 year cycles (1900 - 1964, 1965 - 2028, etc...) This would have gone totally unnoticed except the 2107 files of mine kept getting placed wrong. Well, fixed that issue 😀

ANSI is again working on the Windows side of things. Still need to have a driver of some sort, of course. I've been using ansicon for testing purposes.

Properly detecting re-direction in both DOS and Windows now 😀 (yay! only took me 10 minutes of google searching to figure it out, easier than I thought it would be.) On re-direction, it turns color mode off (strange things can happen as the color routines are only effective on the console screen, or text memory.) If ANSI is enabled, it will include the ANSI codes in the destination file though. So, if you are redirecting for printing or some such, unless the device can use ANSI escape sequences, make sure ANSI is turned off.

Got rid of a ton of wasted cycles on the directory separation routine. Originally, for simplicity, I just used pretty much the same sort routine for directory separation as I did for name/date/size sorting. But if the current test alpha entry is (or is not, if you have directories last,) a directory, there is no need to go through all the test beta entries to see if they need to be swapped. So, if you have 200 entries, you have it set for directories first, and entry 1 is a directory, it will skip it (it's already at the beginning of the list.) Before, it would still scan the entire listing even though the "switch places" code could not be reached until you moved on to the next entry. Directory separation should work a lot faster now.

Sorting is still going to be the primary slowing aspect I'm afraid. Yes, because I allocate memory dynamically, I have to read the directory itself twice, that isn't really that much of a time consumer. With a large directory, there is a noticeable time difference between sorted and unsorted listings. The test code still puts the upper limit of listing for the Windows code over 50 million, but I stopped testing at 3200 or so of actual directory entries (the lag was getting annoying.) The DOS code reports 2849 as the top limit, and that bears out in testing. 2850 entries and it reports "Too Many Files" (cannot allocate the memory.) 2849 entries and it pulls it on up and lists them out, though there is a noticeable delay.

Anyways, back to my bug search.... Going to start working on the Readme file too, I guess.

Anybody find any problems with this latest release? It seems to work fine on all versions of DOS windows that I have access too. I'm starting work on the readme.txt file, and thinking about setting a final (non beta,) release. Would like to know if anyone has found any problems or has any suggestions. I'm thinking of separating out the long time/date and long filename flags, but not sure about that.

There was not much time for me to mess around with retro computers in the past two weeks, So I did not use your program much. Last thing I tried was 'redirect output to file', which worked well.

Sorry for the long delay. Found a minor bug and have been trying to fix it, without much luck. Basically, outside of Windows 7 the disk size maxes out at 2G for some reason. In Win 7 it displays just fine, but not in Win XP, Win 95, or DOS 7 (pre DOS 7 it isn't an issue as 2G is the max for disk sizes anyways.) The conversion code is good, the reading code is good, I just can't figure out where the problem lies.

Ok, I cannot solve the problem 🙁 I'm posting my code in Stackoverflow to see if I can get an answer there 🙁

FeedingDragon wrote:

Updated the colors. Exe was the only thing LightCyan and com the only one LightGreen. Since I had put dll as DarkGreen, making both exe and com light green makes sort of sense. Exe and com are full executables, and dll's are sort of semi-executables 😀 On older systems exe and com files were worlds apart. Com files run faster, but are much more restricted. Exe files can do more, but suffer in other areas. On modern systems, from what I understand, com files are just renamed exe files. Not that it makes that much difference. With faster processors, the difference between old style com and exe files were pretty negligible. The com is just smaller profile, with much smaller memory footprint, exe's use more overhead. But again, hard to tell the difference nowadays. Anyways, segregating exe and com files doesn't seem as important as it used too.

To be precise, IIRC DOS always checked the contents of .com and .exe files to see what they really were. .Exe files have a header starting with "MZ". So even with older DOS versions you could just rename your programs and they should continue to work.
.Com Files start faster, after that they don't run faster. Of course with the exception of memory models with far pointers for code or data, but if you don't need that much space for code or data you can avoid those.
The performance difference between a .com and a "Tiny" or "Small" .exe was probably already negligible with a 386. Space on disk is slightly more with .exe so if you are working with floppies that might make a difference.

Bug fixes to date:
Fixed the "enter/spacebar" routine that I broke when I took the extra line feeds out (*sigh* I miss Borland's "Are you sure you want to do a reassign with that if statement?" when I accidently use a single = instead of a double ==.) The "if LRow is equal to TRows" becomes "make LRow equal to TRows".

Isn't there some compiler warning you can turn on? A short search gives me a level 4 compiler warning C4706 for Visual Studio "assignment within conditional expression". Or you could try an additional lint tool if necessary.

idspispopd wrote:

FeedingDragon wrote:

Bug fixes to date:
Fixed the "enter/spacebar" routine that I broke when I took the extra line feeds out (*sigh* I miss Borland's "Are you sure you want to do a reassign with that if statement?" when I accidently use a single = instead of a double ==.) The "if LRow is equal to TRows" becomes "make LRow equal to TRows".

Isn't there some compiler warning you can turn on? A short search gives me a level 4 compiler warning C4706 for Visual Studio "assignment within conditional expression". Or you could try an additional lint tool if necessary.

I haven't actually looked into that. I figured it was just a nature of different engines look for different things. For example, VS will ask if I'm sure I want to use a comparison instead of an assignation when I use double == instead of single = in a line (example: "x == 37" instead of "x = 37") while Borland ignores those. Would be nice if both were looked for in both engines. Now, there very well may be a setting in VS that allows me to change that, VS has literally thousands of different settings it lets you tweak in the IDE. Borland, not so many. I have the most experience with Borland (Turbo C++ 3.0 - the last one for DOS.) I'm fairly sure Borland won't let me change it in that manner. On its highest setting (other than "Treat Warnings as Errors,") it still lets the == sign pass.

Well, thanks to stack overflow, I've got the problem partially solved. I'm working now to get it to read the drive specs correctly in DOS 7, or Windows 9x booted to command prompt or in DOS mode (without the Windows API routines available.) Not having much luck, and mostly getting snide comments about how I should buy a new system.... I'm starting to get really sick and tired of those. I'm wondering if these people go out to vintage car shows and denigrate the vintage car owners. Do they go to antique stores and tell the owners they need to upgrade? Really, these people's parents need to start monitoring their internet activities better.

OK, despite insults from other users on Stack Overflow, I was finally able to fix the drive size issues. Really, why are people so derogatory to those that want to program in or use older operating systems? I'm just glad that there is "some" moderation on "some" of the boards I posted questions on. The worst insults were eventually deleted from the responses by someone at least. I admit, that some of my responses to those insults were also (deservedly,) deleted as well, but can you really blame me?

There is still a single drive size issue, but I've decided not to try and fix it after all. I really suggest you use the Combined version if you are going to be using it in multiple environments. The remaining issue only exists if you use the DOS only version in an advanced (primarily NTFS,) environment where the Windows only or the Combined version is really called for. The single mode versions don't run any faster than the combined mode version, the only advantage is that the single mode version's file sizes are a little smaller.

Again, if any one finds any bugs, please let me know and I'll see if I can fix them 😀

Great,
Should the latest version not be called v434 now?

Sorry to hear about insults, Vogons is one of the few places where you can mention a single core system without the typical 'upgrade' remarks. It is just too easy to go that direction.

gerwin wrote:

Great,
Should the latest version not be called v434 now?

Yes, but I forgot to change it 🙁 I'll do that now.... Give me an hour or so please 😀