It works fine in Windows XP 32, and the DOS version works fine on a 486 with DOS 7.10.
Seems like a good program, I like the default sorting, and the default colors.
A minor point I don't like is the blank lines it adds before and after the output.
Thanks for this.

gerwin wrote:

It works fine in Windows XP 32, and the DOS version works fine on a 486 with DOS 7.10. Seems like a good program, I like the def […]
Show full quote

It works fine in Windows XP 32, and the DOS version works fine on a 486 with DOS 7.10.
Seems like a good program, I like the default sorting, and the default colors.
A minor point I don't like is the blank lines it adds before and after the output.
Thanks for this.

A minor tweak to change that. In all honesty, the trailing new line was a holdover from when I had problems with color bleeding in DOS. That is, even though I changed the color back to what it was before, it wouldn't go into effect until I actually output a new line. Spaces just wouldn't do it, it had to actually be a character or a new line. It also seems that the system itself adds an extra line at program termination, as there is a blank line that I just cannot get rid of. Can only stop it from printing 2 new lines (by removing the final new line print.)

This is also the reason for the leading new line, otherwise a listing that didn't go into browse mode would output 2 extra new lines at the end instead of just the one I had to put there. Again, a minor tweak to change when the first line is printed, then start the loop at the second line instead.

Now that I'm writing the colors directly to text ram instead of through interrupts or the functions (textcolor and cprintf - the first only existing in Borland it seems,) that is no longer an issue. It doesn't appear to be an issue in the Windows version either. Originally, I just copied the code over directly, then I went through and replaced/changed what had to be changed. The massive re-coding took place later, and was mostly in the subroutines, the core program flow pretty much remained the same.

I'm going to keep testing and minor tweaking for a few days, then I'm going to start prepping a copy of the Win32 version for LFN support. That's going to take some major changes, and will probably break it all to pieces at first. The formatting and display functionality already takes the possibility into account. I'm also going to try and do some more formatting of the help menu, and add in row detection there instead of just column, so you don't have to use another program (like more,) in order to read the entire thing if you have less than 25 rows on your display. I'll also need to add in a notice that all the options (except help, of course,) can be placed in an environment variable ("Final-D=") if you want. So, "set Final-D=/2 /on /a" would set it to display 2 columns sorted by name with ansi color coding by default. Not sure if I need to put in that "-" works the same as "/" for the options or not. I might leave that for the readme file. Lots of little things like that before a final release. I'm also trying to decide if I need to add more or different color coding. My version of HotDir only had a few, but since Access D had the exact same colors for what HotDir marked, and a whole bunch more, I just copied it's list over. I did go through and delete a ton of the definitions it had though, mostly because they were extensions that you just don't see that much (IMHO.) Been considering what some of them should be, marking .dll files for one is a definite.

Also, it had been a while since I did a max list test and the numbers are different than they were. The DOS-16 .exe file caps out at 2849 and the .com at 1355 right now. I had added in a lot since I did that last test, and didn't take that into account. Still a respectable number, but I'm going to see if there is any more tweaking that can be done.

Yes I had the same text color issues when I was working on SetMul in DJGPP. IIRC I could get away with printing an newline or a point "." in the default color there. Anyway, will check out your latest version soon.

Maybe you should update your first post instead of leaving a trail of alpha and beta versions in the forums?

That configuration system through an environment variable is pretty neat. I used to configure access D by using a D.bat every time. But I like your program default output.

So 2849 files max in DOS, sounds fine.
I am wondering what is the reason for distributing a .com version of your program.

FeedingDragon wrote:

MS's new 64-bit OS rules

It's not Microsoft's rules. V86 mode isn't available when the CPU is in long mode.

Just updating the first post is a Lot simpler 😀 Going to do that from now on. In all honesty, I didn't know I could edit a post with replies. Some forums won't let you do that.

As for the .com file... Back when I first started learning (it was the late 80's,) my instructor said I should make .com files whenever possible as they are faster and cleaner than a .exe file. Something to do with fixed load point and some other stuff I don't remember too well. I never had the patience to program full time, and never even finished my first course, but the habit of trying to make small programs into .com files stuck. I figure it doesn't hurt, and I'll just let the end user decide which to use. I'm also in the habit of trying to shave memory use to a bare minimum because of that time.... The source for Access D actually had me shuddering... He reserved huge chunks of memory during program creation. I reserve very little, and just access what I need a run time. The latest version is 1398 files (maybe 1400 after removing the measure code) for the .com file, and that is probably sufficient.

I've eliminated the leading and trailing new lines now. Not sure if I like it, looks sort of cramped to me, I'll give it some thought and wait for feedback.

I also fixed a set of bugs that cropped up on me with my last fix, and even more that cropped up when I tried to tweak my code a bit. I'd still like to tweak it a bit more, I'd like to get the .com file as small as possible. Probably can't get it much smaller, though, without switching to assembly... Considering how little patience I have, assembly is not really an options.

Anyways, new versions available in the first post now. Can't think of any more tweaking to do, going to think on the leading/trailing new lines. Then I'll probably copy the vs project over and start working on a lfn version. Would appreciate everyone's thoughts on this... Would it be better to downgrade the number of columns requested to fit lfn's or to turn of lfn's to fit the requested columns if possible. Right now, if the minimal listing won't fit in the columns requested (try asking it to display 12 columns for example - on a standard 80 column display,) it will start reducing the columns until the minimal info (name & ext,) will fit.

SquallStrife wrote:

FeedingDragon wrote:

MS's new 64-bit OS rules

It's not Microsoft's rules. V86 mode isn't available when the CPU is in long mode.

Sorry about the delay, wanted to re-do my research before replying. It could actually be more accurately described as MS's laziness than MS's rules. Technically, no previous bit structure can run with the processor in a higher bit mode. 16-bit programs cannot run on a system with a processor in 32 bit mode, and the same thing for 32 bit programs and 64 bit mode. There are exceptions, some (not that many, well below 25% I believe,) processors have what I refer to as a half 64 bit architecture, that is, they have a 64 bit mode that works, but they maintain a 32 bit instructions set. A very few also have a 32 bit core included in their 64 bit mode, not sure exactly how that works, but it's moot as only a very few have this. Most only run 32 bit programs through virtualized emulation while in 64 bit mode. This is the same method Win-32 used to run 16 bit programs, and the method Win-64 uses to run 32 bit programs. So, if Win-64 is already virtualizing 32 bit programs, why not virtualize 16 bit programs?

Now, any previous bit mode is almost always supported by higher processors. 32 bit processors can be put into 16 bit mode and run just fine, same thing with 64 bit processors in both 32 bit and 16 bit mode. Thus, you can install and run DOS-16 on a system with a 16 bit, 32 bit, or 64 bit processor. You can install and run Win-32 on a system with a 32 bit or 64 bit processor. In the first case, the processor would be put in 16 bit mode during OS boot, and the same thing (except 32 bit mode,) with the second case. I've been looking, I think there may be some processors that don't support earlier bit modes, but I haven't found any yet (not searching very hard, though, almost all do support this so I haven't given it that high a priority.)

On a side note, Win-32 doesn't do 16 bit well (IMHO.) They run all 16 bit programs through the same virtualization thread. One thread for however many 16 bit processes you are using (drivers, programs, whatever.) I don't know yet if Win-64 does the same thing with 32-bit processes or not. Also, the 4G ram limit of Win-32 is also MS laziness. 32 bit processors actually address 36 bits for memory (that's 64G btw.) They did this in the same way that 16-bit processors address 20 bits of memory (1 M i/o 64 k.) That is, 4 bits for segment, and 16 or 32 bits for address. So, there is no reason why any Win-32 system couldn't address 64G except that MS didn't want to bother with using the segment register with memory management. They also threw out any chance of extended memory handling with Win95 and beyond. That is the method DOS 16 used to handle memory beyond it's 1M limit, by paging in sections of memory in a "window" addressed inside the 1M area. Fairly slow, but it got the job done. Win-16 (3.1) used this same method, but the early Win-32 didn't bother with this because there was no real reason too at the time. I find it strange that technically Win 3.11 32 bit can actually address more memory than Windows XP 32 bit 😒 Win 3.11 32 bit still used the segment register. I haven't actually tested that part, I just know that Win 3.11 is programmed to use the segment register, and that a 32 bit processor does have said register in 32 bit mode extending memory addressing to 36 bits. I also believe, though I'm not 100% sure, that Win 3.11 32 bit also had code for extended memory handling. Win 3.11 32 bit, used the same base code as Win 3.11 16 bit, it just upgraded to a 32 bit instructions set, and put the processor into 32 bit mode. Not sure how it threaded 16 bit processes, but I seem to recall that it had some problems there. Haven't done any "real" research in this area.

I call it MS's rules because I package it in with a lot of things that are "not" laziness. Such as the strictly enforced MS certification key for kernel mode drivers. Install a Win-64 OS, pull out your favorite programming package, write a driver and try to install it. Unless you pay a 3rd party for a certificate license, then pay Microsoft (if you didn't pay the 3rd party extra because they paid MS for you,) for a certification, you cannot install that driver. Even on your own system. They say this is a "security" feature, and I can see that, but the only way to bypass this is to turn off 90+% of all the security features on your system. Personally, I think it's MS's way of generating more revenue. Ok, that's fine if they limited it to licensing for professional drivers (AMD, Nvidia, etc....) I'm not a fan of it, but companies have been doing that with proprietary systems from the very beginning. But when the end user is forced to either pay or turn most of their security off, that's going too far (IMHO.) Win-32 would just throw up a security warning, and let you install anyways. Letting the end-user make the security choice on a case by case basis. Something trying to install itself secretly? Well, the warning pops up, I say "Wait, what's this," and hit "decline." Trying to install something I wrote myself? Ok, just hit "install anyways." Win-64? "this driver is not certified, go #&%@ yourself, goodbye." Ok, the curse word is actually my response, not included in Win-64's actual message. Sorry, the certification thing is a pet-peeve of mine. It is one of the major detractions of the Win-64 system.

Forgot to ask, I'm starting the alterations to use 64-bit math with the Win-32 version (__int64 or long long, instead of the 32 bit long limit in 16-bit DOS.) Now, the math I used to convert the 32-bit values of 16-bit DOS to handle the 64-bit sizes generated on modern systems (since I wanted to avoid floating point math,) was a bit of a headache, I basically ended up using binary units (1024 bytes in a K, 1024 K in a M, etc..) because the split values (2 32-bit variables instead of one 64-bit.) I could have done it the other way, but it would have required a LOT more code, when I got to 800 lines of code just trying to use the decimal system(1000 bytes per K, 1000 K per M, etc...) I gave up and went binary. Now, the computer measures in binary usually, but most companies advertise decimal. A 500 G HDD is 500,000,000,000 bytes, for example, instead of the 536,870,912,000 it is in binary measurement. With 64 bit math available now, I can go either way. I'm leaning towards keeping the binary measurements, so that all versions will produce similar results. But would like opinions on the matter.

FeedingDragon wrote:

16-bit programs cannot run on a system with a processor in 32 bit mode

Yes they can, because Virtual 8086 mode is available from within i386 protected mode.

FeedingDragon wrote:

So, if Win-64 is already virtualizing 32 bit programs, why not virtualize 16 bit programs?

Windows x64 doesn't virtualise 32-bit applications, it thunks them.

http://en.wikipedia.org/wiki/WoW64

FeedingDragon wrote:

One thread for however many 16 bit processes you are using (drivers, programs, whatever.) I don't know yet if Win-64 does the same thing with 32-bit processes or not.

WoW64 doesn't work that way, see above.

FeedingDragon wrote:

Also, the 4G ram limit of Win-32 is also MS laziness.

No, sorry, this has been done to death around here lately. The 4GB limit is a hard limit in most contexts. The CPU can't execute anything above 4GB, because the EIP register won't go that high, so any data stored above 4GB can only be user data, thus limiting its usefulness.

SquallStrife wrote:

Yes they can, because Virtual 8086 mode is available from within i386 protected mode.

Um "Virtual 8086 Mode"? Doesn't the word Virtual give it away? It is a virtualization that is contained in hardware on 32 bit processors (most of them at least.) Win95 and beyond did away with using hardware virtualization and just used software instead. On faster systems than 99% of the 16-bit software was designed for, this made no real difference.

SquallStrife wrote:

Windows x64 doesn't virtualise 32-bit applications, it thunks them.

http://en.wikipedia.org/wiki/WoW64

This is a matter of semantics. Virtualizing, Thunking, read the wiki, it amounts to the same thing. It builds a false layer that makes the 32 bit process think it's running on a 32 bit system. It does this in two way, 1 - by interpreting the instruction(s) and converting, and 2 - when the first won't work, by briefly switching the processor to 32-bit mode, executing the instruction(s) and switching back. That is the difference between virtualization and emulation. It also doesn't address why they don't build a similar engine for 16 bit processes. Or why they lock down kernel mode so hard that it's either inaccessible, or almost completely insecure.

SquallStrife wrote:

WoW64 doesn't work that way, see above.

Actually the wiki doesn't specify whether WoW64 is a single thread or multiple threads. All it really says is that fewer 32 bit threads are available through WoW64 than are available on a 32 bit OS. Which sort of implies that it's single thread, but doesn't actually state as much.

SquallStrife wrote:

No, sorry, this has been done to death around here lately. The 4GB limit is a hard limit in most contexts. The CPU can't execute anything above 4GB, because the EIP register won't go that high, so any data stored above 4GB can only be user data, thus limiting its usefulness.

The problem with that is that everyone forgets that the EIP can be modified by the segment registers as well (MS just doesn't do it.) In particular the CS or Code Segment register, which tells the processor which segment page the currently running program resides in. 32 bit processors also have 5 other segment registers, 4 general purpose, and 1 stack. So, a 32 bit processor can run a program in 1 4G segment and allow that program to access ram in 4 other completely different 4G segments, while maintaining a stack in a 6th completely different segment. All this without any fancy memory switching. That alone is 24G of space in use all at once (not 4G.) Now, set aside 1 segment for HW control & access, and don't count the stack, you still have 16G of space for a program to play around in, and that's assuming you never actually "change" any of the segment registers (on older systems this was called paging, store 64k/4G in one segment, the change pages to store more, changing back when needed.)

Just like on 16 bit systems, programs "can" span segments as well. The problem is that when a program spans segments, the processor has extra working switching the CS and resetting the EIP. For example, code is running in segment 0x1 (4 bits are all that's significant for segment pages,) and reaches instruction at address 0xFFFFFFFF (that translates to real address 0x1FFFFFFFF,) the next instruction is at 0x200000000, so the processor has to change the segment indicator in the CS to 0x2 and the IEP to 0x00000000. This slows things down, but is perfectly functional. Also, just like in old systems, there are some segments where a program cannot reside. these are reserved segments for HW access & control for the most part. on an older system it was everything below segment 0x1 (I believe,) and above 0xA. Though most people aren't aware that the latter limit could be modified if you didn't need graphics, 0xA was the graphics HW access point, if you were only using text graphics, that could be bumped to 0xB. On 32 Bit systems, chunks of segment 0x0 is reserved for backwards compatibility, reducing the size of the code that can reside there without page straddling (see below.)

Even doing away with segment spanning in code, that still leave a full 4G for pure code (no data, no constants, no variable, just pure instruction sets,) and 60G of accessible data, 16G of which can be accessed without doing any paging (leaving the segment pointers fixed during program execution.) So, why is Win-32 limited to 4G for absolutely everything (program, data, & stack??) Because, when Windows first went 32 bit, they discontinued use of the segment registers in favor of speed (and at the time, 4G was ridiculously roomy.) This was probably a good decision at the time, but why does the limit exist now? Either MS is too lazy to upgrade the code, or they are too greedy for people to buy their 64 bit OS. I chose the former.

This is simplified a bit, the actual segment pointers are 8 bits, but only the upper 4 are significant, the lower 4 overlapped with whatever register they were working with (EIP, SP, etc...) So, segment 0x14 address 0x0F000000 is the same as segment 0x10 address 0x4F000000. This is the germ of the difference between "huge" and "far" pointers. A bit of trivia that is not exactly germane to the discussion (other than it shows why changing pages for the EIP is so slow.) This can get rather complicated as address 0x14 address 0xFFFFFFFF is perfectly legitimate (even though it is physically 0x23FFFFFFF, or segment 2 address 0x3FFFFFFF) and is considered the "end" of a single page. This is called page straddling, a virtual page actually "straddles" a physical page border. The physical memory of 0x140000000 - 0x23FFFFFFF is considered a single page, because it is segment 0x14 address 0x00000000 - segment 0x14 address 0xFFFFFFFF.

http://www.acm.uiuc.edu/sigops/roll_your_own/i386/regs.html

Also, we are getting off topic. If you want to start another thread, pm me the address, and we'll continue there.

Ok, bug fix releases of the 2 original versions, and first release of Windows version using 64 bit math. I have no idea if it will work in a 32 bit OS (which is why the 32 bit math version is still available.) If it works, great, I'll keep the 32 bit math version around for when I start building Win9x versions (in case it's needed,) and switch to 64 bit math (it's a lot easier to work with.) If not, I'll set that aside in case I decide to build a 64 bit version.

Your D-Win400 works on windows XP 32-bit. the size calculations match.

Yesterday two small things came to mind:
- Can .EXE color be the same green as .COM, So it stands out more from the rest?
- Can .MID be colored blue like other music files .XMI/.MOD/.MP3?

I like the version without blank line margins. space is precious in stock text mode.

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.

I honestly don't know what happened to the MID entry.... It was there when I first started. Computer gremlins must have stolen it at some point. It's back now. I didn't change the version numbers, only changed the color coding table. Try them out and let me know what you think of the colors, as well as anything else that you can think of. I'm getting used to the more cramped display, so I'll leave the extra line feeds out. I had considered putting them back if the total displayed rows was enough less than the total available rows, but decided against it.

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".

Also fixed the "centered" "<Browsing>" text broken at the same time. Taking the new lines out meant "not" automatically sending a new line when text was auto-scroll printed (like original print and enter/spacebar print.) Which meant that I had to manually do so when necessary after an auto-scroll print (to put the <browsing> notice back up.)

Also the 1001 bugs created when I converted to 64 bit math. Almost every last one typos 🙁 Then there was all the "Are you sure you want to put a 16 bit number in a 64 bit variable?" messages along with the "if you put a 64bit number in a 16 bit variable, you might lose data" messages. The latter is upsetting because I'm doing it on purpose in those cases 🙁

Things like this reminds me why I never became a professional programmer. Oh well, it my own personal project, I'll just have to suck it up 😀

Ok, some bug fixes and code tightening done. Also made small changes to make the 2 versions closer to the same.

Note: The DOS stub is still limited to 2849 files & directories. In the end, I'm pretty much going to keep the help/error messages as they are. I will be adding a readme.txt file eventually with helpful information (such as the environment variable option.) Right now, I really need someone willing to test it on a real 95 & 98 system. I'm getting strange errors in VPC with 95. They are completely random, and I cannot figure out why they are happening. Mainly, the colors change for no rhyme or reason. Halfway through a single print even. It works just fine on Win7 64-bit. I'm honestly starting to believe it's something with VPC.

Regarding the version with the updated green .exe colors in DOS. It seems the file sizes are not making any sense?

Ack... OK, no idea what's up with that.... Got new HW in, as soon as I get stuff re-installed, I'll try and figure that out. Going through the code, I can't see what could be causing it. It seem rather sporadic though. Some of the file sizes match (what the vanilla dir command gives.) I'll probably find it's something silly though, typo or misused symbol. I'll also try increasing the file strip size by one byte, in case my info on stub files is a little off. I really think it's in the code though.

Yes on second look most sizes are correct, it tends to choke on file sizes between 100kB and 1MB.

gerwin wrote:

Yes on second look most sizes are correct, it tends to choke on file sizes between 100kB and 1MB.

That could actually help quite a bit. Will have to look at the code to be sure, though. I didn't notice a pattern myself. But then, I'm seriously multi-tasking right now. Install, install, install 😒 Pain in the rear getting all my SW back on the system.

Remember what I said about something silly? Well, it turns out that I was using an "unsigned short" variable to temporarily hold the "unsigned long" file size while converting it to text for display. The "unsigned short" (or just "unsigned" in c++,) can only go up to a max value of 65535. The "unsigned long" can go up to 4294967295. So everything above 65535 (or past the 16th bit,) was getting truncated. Got it fixed, but I can't build it till I get everything re-installed. Going down a list, and I'm not there yet. Have to take a nap now though, been working on getting my system back up all night.

Ok, sorry about the delay, ran into a problem with another bit of code I'm working on in the middle of reinstalling my system. Got the minor fix in place. As far as I can tell with brief testing, it works great in Win7-64bit, works great in DOSBox, works great in VPC DOS boot. Still having problems in VPC windows 95 boot. Anyone with a real win95 system willing to test it out for me? I've been over the code with a fine tooth comb, and cannot figure out what's going on. Random color changes, color bleeds that make no sense. Times when (for no apparent reason,) it reports that 20 files is too many, then on the next boot will display 500 without a batting an eye. I can't figure it out. Is it a 95 thing, a VPC thing, or am I missing something simple in the code again.