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
aefdisk 2 /delall /show
aefdisk 2 /nolimit /pri:200000:c:1 /show
aefdisk 2 /pri:20000:c:2 /show
aefdisk 2 /nolimit /pri:300000:c:3 /show
aefdisk 2 /pri:0:7:4 /show
aefdisk 2 /deactivate /show
aefdisk 2 /activate:1 /show
aefdisk 2 /nolimit /formatfat:1:Drive_C /show
aefdisk 2 /formatfat:2:Drive_D /show
aefdisk 2 /nolimit /formatfat:3:Drive_E /show
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?
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.
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.