Jump to content

Open source aefdisk on github


ShadeTreeLee

Recommended Posts

Since mid April of this year, one of my favorite DOS programs has gone open source on github.  A re-director link will take you there from aefdisk.com.

 

Only trouble now is that the only version of this program that supports large FAT32 /nolimit switch (>137 GB) is the open source one and it's zip file doesn't include the executable, just source code for it.  "Needs Borland C compiler/linker for DOS" which I never learned how to do.  I do have Borland C++ 4.5 installation CD, will this get me there?  I don't even know this much about compiling PC code, my 'code' expertise begins and ends with the atari 8-bit.

 

Anybody who knows how might go ahead and do that for the unwashed masses here?  Provided this request meets with moderators approval in the first place.  A yes or no nod would be most appreciated first as I truly intend to affront no one.  But especially the moderators.  TIA one and all.

Link to comment
Share on other sites


It's assembly so it just needs TASM and TLINK. In "makefile" you can see the compile parameters:

 

TASM aefdisk /m9 /q

TLINK aefdisk /x

 

There are three errors with my older version of TASM, one easy to fix, the other two need more familiarity with the subtleties of TASM. I assume v4.5 or v5 will do, but haven't tried.

Edited by shae
Link to comment
Share on other sites

Thanks for that anyway, it really does help as I'm stumbling along pretty good considering my entry level knowledge here.  4.5 is a no go as it lacks TASM, so downloaded 3 something package.  I'm getting four errors, two of which are the include files which I'll just cut and paste into the .asm file, if that sort of end around will suffice.  What it doesn't seem to understand is a couple of label lines.

 

MBRloader       label  - this is an error where

 

dataend        label   - isn't  WTH???

 

and then this is the other error that makes no sense to me right off:

 

wildcard?    db    0        ; if HD number is '*'

 

and right in the middle of a bunch just like it - I have no idea why that one could be wrong.  I'll keep plodding along though, perhaps a higer version of TASM is in order?  I've checked for multiple label definitions and I can't find any, unless they happen to be reserved words I'm out of guesses for the moment.  Maybe ten passes could be tried instead of 9?  We have TASM for cross assembly to the atari 8-bit believe it or not, but I've never used it there either, I kinda doubt it's a borland product and the name is the only thing ripped off there.

Link to comment
Share on other sites

Yep, I was thinking the same thing many times, but i'm on the trail like a houndog now.  It's 3.1 and it's out there, if you'll go to the org site after searching for 'Borland C++ 3.1'.  So is 5.3 but it has version 3 TASM and if I used 5.3, TASM is going to be under the BC5 path.  Makefile has borlandc as part of the path and I read about that connection in the 4.5 text files on my CD finally pertaining to proper upgrading which appears to be wholesale directory deletion until you get to 4.5 and then it's a file list to back up, do this, and do that.   Like being tossed into the deep end of the pool to learn how to swim, I think the 4.1 version I got on the web has been stepped on and just doesn't work right.  Kinda odd version 5.3 is still using version 3 TASM to me.  It also has TASMX for Windows DOS box and from there they go to TASM32 but it can still build 16 bit code if you link it with TLINK, which also comes in 32 bit flavors if that is your bent.

 

As to my problems with no TASM in 4.5, well that's because I installed the run from CD files which don't do the 16 bit stuff.  Needed to navigate to the folder where CMD16.PAK is at and run that install executable and then I would have gotten TASM just like that.  I see 5.3 is built exactly the same way too.  And I might still do that after I clean house and put 3.1 on there all alone to do this with.  Jeeze, if I can do this is there even a need to post it when done?

 

Further info here for those stuck at too high a version:

A) Installing over previous versions of Borland C++.

As a general rule, it is not recommended that you install
Borland C++ 4.52 over any version earlier than 4.51.
It is recommended that you delete the Borland C++ directory
tree (BORLANDC if you have Borland C++ 3.1, BC4 if you have
Borland C++ 4.0, or BC45 if you have Borland C++ 4.5) prior
to installing. In addition, you will need to delete the
following files in the Windows directory (WINNT under NT, WIN95
under Windows 95): owl.ini, bcw.ini, borhelp.ini,
openhelp.ini, winsight.ini, workshop.ini.

If you are installing over Borland C++ 4.0 or greater,
you need to backup the RTL BIDS and OWL .DLLs prior to
deleting the directory tree. Otherwise, any applications which
need to link these libraries at runtime will need to be rebuilt.

If you are installing over a previous installation of
Borland C++ 4.51 or 4.52, you need to delete the Group file
for Borland C++ (Under Windows 3.1, this is
WINDOWS\BC45.GRP). The installation program cannot
properly create this file if it already exists on your
machine.

 

I got that error prone 4.1 TASM in a version 5 bundle, and then found a better 5.3 bundle.  Kinda curious what's in 4.5 now, but that will have to wait until after some sleep and some housecleaning.

Link to comment
Share on other sites

Sounds too complicated for me at the moment, especially since I haven't done any ASM work in a handful of years.

Moreover I don't quite trust the real site I found the package at. Maybe someday.

Good luck!

Link to comment
Share on other sites

Here. I didn't test it, so use with caution and check if the specific modified functions do the expected thing. The compiled code, at least, looks okay.

 

The errors you saw aren't what I saw. The problems here were lines 2743, 2919, 2921.

In the first, it didn't like having ES inside the brackets:

okdoformat: cmp word ptr ES:[bx+1feh],0aa55h
In the other two it wanted the explicit addition of DWORD PTR:

mov DWORD PTR es:[bootbuffer+offset freeclust-offset bootsec32],eax
BTW, some label names in the code include a question mark. A strange practice, and it's surprising TASM accepts it.

 

I'm not sure what TASM version or settings the author used but it'd odd that it wouldn't compile as is. Maybe it's possible to use global settings through an INI file or an environment variable, and this wasn't included in the makefile?

And I don't get TASM's version numbering. I downloaded something which the README calls v5.0, yet TASM.EXE is v4.1, same as the one I had before (though I didn't compare the EXE, can't do that right now).

AEFDISK.ZIP

Edited by shae
Link to comment
Share on other sites

Thanks Shae, I'll compare yours to mine as I had complete and super fast good results as soon as I cleared the other installations and put on the org based 3.1.  Too easy, I couldn't believe it.  During testing of mine, it does require the /nolimit switch to be in front of /pri:200000:c:1 switch to get a FAT32 first partition of 200 Gigs.  Otherwise it resets the size to 127 Gig as per normal.  

My possible bad on advice for TASM32 as the documentation says it's primarily for creating 32 bit debug information and does not suggest it's use for 16 bit work at all.  I had read somewhere that it can serve dual purpose 16 bit and 32 bit work, but I haven't seen that in the documentation yet, so better treat that as fringe advice at best.

They do the question mark in atari cross assemblers and it does bug me too, but then so does the colon in label names which you just glided over as not much at all.  I'll just have to get used to both it seems.

I have 2744, 2920, and 2922 written down in front of me, and that due to a blank line I inserted to attempt to get around the label problem on line 16, I saw a similar label equate line not too far away and he had a blank line under it so I'm thinking maybe that's it.  I didn't go back to correct it when I found out that wasn't the problem.

I tried to use the makefile but 3.1 didn't want any part of it as one of the C++ installs I tried would use it.  I just did TASM aefdisk and I had zero errors and an .obj file which I then did TLINK aefdisk with and there was aefdisk.exe pretty as you please and just that fast.  One thing I did do different was to lauch Throttle 6 with autoexec.bat file to slow DOS mode down from 3 GHz - I've had that problem during the making of vmm32.vxd during 98 installs and forgot completely about the issue in earlier attempts.  DOS was never meant to fly that fast methinks.  Much better documentation with 4.5 and 5 versions of C++, reading about where you can make a big swap file expressly for the use of these 16 bit borland programs such that very large projects can be done in the limited memory environment DOS has.

Since you didn't report problems with line 16, 43, 44, and 472, I'm thinking we lay them at the foot of the GigaHertz god for a sacrifice?  Throttle may have eliminated those errors entirely to wind up with exactly the same problems you went in and corrected the code on, nice work, thanks for showing us what was wrong and the straight forward way to write code.  Obviously 3.1 is buggy in that it allows such errors so no real need to keep it around.

To the best of my knowledge they quit making 16 bit TASM at version 4 something, as I stated before one 5.3 package had version 3 in it, which makes me anxious to see what is in the 4.5 I have when I get around to installing it in the correct manner this time around.  I can't believe the prices they want for this 4.5 CD - I got it as a throw away so many years ago I can't even remember when or how.

So a bit later than the above, I have tested both mine and yours.  Mine is bigger for some reason but it still works, just like yours does.  There are other bugs with it though, it won't make a label on /formatfat:1:Drive_C command but will if the partition is <137 even if the /nolimit switch is before anything else.  So we have bad switch handling inherent in this to start with is my assumption and this is verified by using /show in combination with /label:1:Drive_C where it won't show afterwards as well.  Lower case is kludged to upper case for drive labels as well.

Installing 4.5 correctly got me the exact same situation I had before - no TASM with this at all.  TLINK version there is 7, can I assume that even borland couldn't keep their act together at this point in time? Using transplanted TASM 4 with it results in a larger build than yours as well although I didn't do a file compare with the 3.1 build, so I'll have to do that someday. Looks like I'm on the hunt for borland C++ 4.02 CD release.  Attempting the build with TLINK version 5, it want's a DPMI manager file to be loaded and errors out when it can't find it.  Version 7 doesn't do this but my build is bigger than yours for some reason there - I assume it's cross versions of TASM and TLINK until someone straightens me out on why my end product with 3.1 and 4.5 kludge is bigger than yours.

 

Link to comment
Share on other sites

Did you use the parameters mentioned by shae in post #2?

TASM aefdisk /m9 /qTLINK aefdisk /x

These are mentioned in the original makefile and they could make a difference in code size.

You may build a batch file in the same folder, add the above commands to it and launch it.

Link to comment
Share on other sites

Is it TASM.EXE v3.1 that compiles it without modification? I wouldn't say it's buggy, since these aren't really code errors. If anything, v3.1 might be more lenient, which is not necessarily a bad thing. Maybe v4 is in a strict mode by default, but can be switched somehow to the same relaxed mode as v3.

TASM and TLINK versions don't have to go in tandem. TLINK is probably used with all other languages as well.

A colon in a label isn't part of the name, it's what terminates a label name inside code parts. Otherwise it would try to interpret it as an opcode.

TLINK's /x parameter just prevents the creation of a MAP file, so it's not important. You can use the MAP files to see why the EXEs from different versions of TASM or TLINK end up being a different size.

Edited by shae
Link to comment
Share on other sites

Drugwash-

I thought I did try that angle with no joy, but a batch file would work much better and I'll try that, thanks. But IIRC, the switches come first followed by the filename (with NO extension) to be worked on for those following along at home. TASM 3.1 only needed 3 passes so m9 switch is overkill, the other switches are default modes anyway, again IIRC.

What I did find odd was that when I went to verify the error codes from before, now they don't match. It's as if aefdisk.asm has grown by x amount of bytes in the middle to such an extent that the error lines with fixes are no more to be found at 2743, 2919, and 2921. The code with fixes are 20 something lines higher and the line numbers agreed upon by all three of us now contain lines that are NOT those that were fixed. So while I'm trying to figure that part out, I can't replicate it again. Just leaving even more confusion upon the growing heap of it I already gots.

But following that angle on out a ways, it's easy to see that if in the process, some code snippet was replicated within the .asm file then it sure would stand to reason that the results would be bigger. His 20 Kb, mine 21 Kb. There also should have been warnings about duplicate labels I would think, but my thinker has had quite a workout lately and can no longer be relied upon. I'll let the dust settle some first and then plug away when I can. If I ever find the why of mine being larger and it's actually important, I'll drop back in and post about that, until then, I'll just use shae's version with lots of gratitude. Thanks, everybody.

Here is the batch file I used to do a 750 Gig SATA drive with, wound up with a 195 gig NTFS partition in fourth place. Halfway wanting to dual boot this with 98 on the second, but not sure I can locate all the drivers I need for the HP dc7600 it's going to live in. Need 98 SATA support to start with. XP on drive C.

aefdisk 2 /show

pause

aefdisk 2 /delall /show

pause

aefdisk 2 /nolimit /pri:200000:c:1 /show

pause

aefdisk 2 /pri:20000:c:2 /show

pause

aefdisk 2 /nolimit /pri:300000:c:3 /show

pause

aefdisk 2 /pri:0:7:4 /show

pause

aefdisk 2 /deactivate /show

pause

aefdisk 2 /activate:1 /show

pause

aefdisk 2 /nolimit /formatfat:1:Drive_C /show

pause

aefdisk 2 /formatfat:2:Drive_D /show

pause

aefdisk 2 /nolimit /formatfat:3:Drive_E /show

pause

As per previous report, only Drive_D is labeled as DRIVE_D. /show works here just fine, but not with /label:#:name command. Didn't test it with /show first but that may work after all even though /show is listed as a command and not a 'goes first' switch. /nolimit switch made no difference on /formatfat commands, I have them here just to show I tried it, I tried it both ways - still no drive label under /formatfat command when partition is >137 Gig. End of the day, I'll set it up differently than above due to active partition flag issue. Have to delete the first slot partition after the second is installed, then do /mbr on it after formatting it. Then redo the first slot and finish with the last two slots, then deactivate all, then activate 1 and 2 slots and it should boot the second partition after XP installs it's boot manager in slot 1 which I then mangle with DOS mode debug script to give me a choice menu at boot up that includes 98 on drive D. Then instead of installing 98 to C:\Windows as per usual, I enter instead D:\Windows and 98 does just that and loves it. That's the plan anyway. /mbr operation being essential to the linking of boot sector to future home of 48 bit LBA aware io.sys. /mbr operation is not steerable (why not?) and must have an active partition flag or the linking doesn't take place. No link, no boot.

 

Is it TASM.EXE v3.1 that compiles it without modification?

Yes.

 

I wouldn't say it's buggy, since these aren't really code errors. If anything, v3.1 might be more lenient, which is not necessarily a bad thing. Maybe v4 is in a strict mode by default, but can be switched somehow to the same relaxed mode as v3.

I'm with you, but I had an .asm file stepped on right in the area of said not really code errors. Mighty fishy to me, I'll revist this issue for sure before hollering wolf, but I'm packing ammo just the same. 2nd time around I'll be looking for size changes in .asm files too. I could have looked the first time it happened, but the concept of it hadn't dawned on me until after I had cleaned the slate.

 

TASM and TLINK versions don't have to go in tandem. TLINK is probably used with all other languages as well.

Hearing you loud and clear again, but that first one is the understatement of the year for me - I haven't found two matching since I noticed that I maybe might should be using them even somewhat close !! And at least one doesn't play at all if it can't find it's friend. Where he can be found is something to watch for too.

 

A colon in a label isn't part of the name, it's what terminates a label name inside code parts. Otherwise it would try to interpret it as an opcode.

Oh, boy.

A long time ago this Rockwell outfit published a 10 pound manual on what was what and how all 6502 assemblers in the future were to behave in ALL such manners as you explain to avoid such discussions as this one, and no one has listened to the word of that particular God ever since. Long story short, it is what it is.

I can see how the colon could be essential for that on these processors, but in 6502 work it is part of the label name as it's shown to be so in the cross reference essentially just cluttering things up there. The delimiter for labels there is first space character, op code then is any line starting with a space or a space after a label. Really hard to debug this kind of source so sometimes it's two spaces required, but not always and round we go again. This ride just does not stop. I yeild. Because each of these quirks can be made to be darn handy and very useful in very clever ways. Tom8toe, tom-auto.

You guys need it for that purpose, I can see that much already, nice to finally know this one at least has a genuine source of need. Your camp may have inherited the question mark from us where it used to be a non-cross referenced short branch label separated by .LOCAL regions for question mark reuse (???? vs ??????) since we can't do long branches anyway - but that's a really stupid and confusing idea all by itself. We can still do that, but I've never seen source written in the last 30 years that actually does it. Evolving madness. The real excuse for it at least in our camp is pandering to lazy typists. Someone's 'must have' idea that really wasn't so much needed. I don't think code anywhere was ever written with such blinding speed and ugency as to miss the spacebar by one tap where two were needed. A pipe dream to write usable, bug-free code at speeds the lousiest keyboard can't keep up with.

 

TLINK's /x parameter just prevents the creation of a MAP file, so it's not important. You can use the MAP files to see why the EXEs from different versions of TASM or TLINK end up being a different size.

Well that's why I found one of those files then. I looked at it this stranger with a familar first name, but that's all I can really remember about the encounter. Now that I know what it's for, that will start to help a little, thanks.

The stepped on .asm file may have been a result from the previous attempt where I wasn't throttling the CPU too, hazy confusion is also a factor - I shall endeavor to duplicate using this trick too. It's wicked evil when DOS mode does this at 3 GHz, that much I do know. And then I could forget all about that part?? I'll blame it all on no speed limit for the moment and see how easy it is to repeat those results. I know I stepped in it pretty fast, safe bet I can do it again.

Thanks a lot guys, I wouldn't be at this point without you, but I have a few days lost to catch up on now.

Link to comment
Share on other sites

I thought I did try that angle with no joy, but a batch file would work much better and I'll try that, thanks. But IIRC, the switches come first followed by the filename (with NO extension) to be worked on for those following along at home. TASM 3.1 only needed 3 passes so m9 switch is overkill, the other switches are default modes anyway, again IIRC.

You're welcome. I had already forgotten how to compile ASM but luckily remembered about the old WLL project so I looked through its files and found the batches. I never managed to work with a makefile for some reason, maybe VC6 interferes or I'm not as bright as I thought. :D

 

Indeed, the switches come first and filename last, at least that's how I found them in my old batches. In my reply above I had just copy/pasted from shae's comment. It's possible that some compiler+linker combination accepts the other syntax too, though. Haven't tried that. Actually I'm not much into ASM lately, got my plate full of other things. Was just trying to help a bit.

 

As for the rest of your project I'm not sure 98 will be happy being installed on drive D. I'm not even sure that will be possible. Anyway, if you first install 98 and then XP, the latter will ask to replace or preserve previous Windows version, so if you choose to preserve 98 you should get a boot menu to choose between 98 and XP. Well, at least in theory - haven't done multiboot in a very long time. There are topics about that around, I'm sure you'll find all the necessary info.

 

For the 98 SATA driver you may either set the SATA interface in legacy mode in BIOS (which may slow down the drive operations) or purchase the SATA driver/patch (can't remember which is what) from Mr. Rudolph Loew (find him on these boards). I believe there are topics on that subject too.

 

Good luck with your project! :)

Link to comment
Share on other sites

One turn deserves another back - you can have makefile work for you too. Get the 3.1 from the org site and install it. Replace TASM file with 4.1 version like I did and you are set. Just type in MAKE, which will then launch and load MAKEFILE and run from it launching both TASM and TLINK - boom ya done.

I couldn't get that to work with any other installation of C++ either. I did have to modify the last two lines of the MAKEFILE for aefdisk though since they tell the system to delete *.obj and aefdisk.exe. I kinda wanted to keep those around long enough to use them !! This version is where the 5.1 TLINK is from that wants a DPMI manager and apparently it's in here as it doesn't complain about not having that anymore.

Read more about XP install first and then 98 after here

http://www.dougknox.com/xp/tips/xp_repair_9x.htm

I know it's backwards to the normal way to do dual boot with XP, but my network printer can only install from Drive C and XP wants to run the network, so my hands are kinda tied there. 98 will have to live on another drive. Loew has already sold me the memory patch, I was thinking the SATA driver was from another source but will look around and find out, thanks.

I'm writing this on a Dell Dimension 2400 dual boot XP/98 box right now - it's where I do the TASM stuff at. It's PATA so no extra drivers needed there, the HP is SATA and has no emulation for PATA so it must be a genuine SATA driver system for 98 or it can't be done. Insane part is that it has a PATA CDROM drive on secondary IDE channel, but one can not ever have a slave drive on this cable, it won't work, can't work. It already is SATA/PATA half and half except it's topped out at three drives. They spend all their profits castrating these machines so we can't live without them. Dell AND HP AND Xerox.

So I have this dual boot XP/98 system where metapad v2 says the line with the first error in aefdisk.asm file is at 2756 and when you run the same metapad v2 in XP instead of 98, it correctly says the line is 2743. What is going on here?

Is this the only troubles I've ever had? Metapad? Is there some ansi 98 thingy that I didn't install that would make it do these kinds of horrible things in 9x and fly straight with XP? I can't even remember what my problem was at this point.

I am able to compile aefdisk at full throttle and I wind up with a file of the exact same size but with one byte different.

Comparing files C:\TC\His\AEFDISK.EXE and C:\TC\My9\AEFDISK.EXE

0000001F: 71 50

I don't think this makes a critical difference at all. This is with TASM 4.1 and TLINK 5.1. With version 3 TASM no errors with orginal asm file, but some dozen different bytes scattered throughout. With 3.1 I get:

*Warning* aefdisk.ASM(2743) ":" operator ignored

So DOS can count lines correctly - why can't metapad?

This file also same size with the exact same dozen or so differences throughout.

I'll use 4.1 with the 3.1 org package that has a working MAKEFILE system. At full throttle. What do I do about metapad? That seriously bent my brain.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...