drac030 Posted February 21, 2020 Share Posted February 21, 2020 (edited) Not sure if this is a bug in SpartaDOS 3 or maybe a misconfiguration (but I have no idea how to fix it in the latter case), but here is what I stumbled upon some day: I have a binary program which consists of several init segments and one run segment. This program loads fine and works under DOS 2.5, DOS XL 2.30, MyDOS 4.55p, BW-DOS 1.30 and, last but not least, SpartaDOS X. But with SpartaDOS 3.2d, 3.2g and 3.3a there is only a less or more spectacular crash during loading. I have found out that this crash occurs, because after the second init segment SpartaDOS 3 thinks that the loading is finished, thus (since the run vector has not yet been set at this point) making a call to the "beginning of the program", i.e. the first init segment, which at this time is of course long non-existing. Now the second init segment opens and parses a configuration file. And this - particularly the OPEN call - causes all this confusion. The file does not even have to exist: it is enough to make an OPEN 4,"D:FOO.BAR":CLOSE in an init segment to trigger this problem. If this is not fixable in a simple manner (like by changing a default parameter in SpartaDOS binary), I would say that this looks like a flaw disqualifying SpartaDOS 3 as a DOS. For opening a file during loading a binary is to my knowledge in no way a forbidden operation. And even DOS 2.5 tolerates this well. Edited February 21, 2020 by drac030 1 Quote Link to comment Share on other sites More sharing options...
Marius Posted February 21, 2020 Share Posted February 21, 2020 Perhaps @Stephen J. Carden knows more? Does the bug also occur on Real.dos? Could you post an example test file? Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 22, 2020 Author Share Posted February 22, 2020 I tried Real.DOS (build 30) and yes, it also crashes in these circumstances. But I have to say that I cannot now reproduce the behaviour of jumping to the first segment that was loaded, although I was sure that I was observing that while debugging what is wrong with the original program. Now (with the example below) the DOS's behaviour is that after returning from segment 1 it simply at one point jumps from the middle of its code to the middle of nowhere. So maybe it matters after all if the file being opened exists or not... or there are other factors I did not see. .in ..>maeinc>sysequ.mae .out sd32down.obj .org $3000 ; SEGMENT 0, NOT STARTED begin0 ldx #<txt_err ldy #>txt_err putline txa ldx #$00 sta icbufa,x tya sta icbufa+1,x lda #$ff sta icbufl,x lda #$09 _xciov sta iccmd,x jmp jciomain txt_err .byte "Error!",$9b end0 ; INIT SEGMENT 1, STARTED AT INIT1 .org end0+123 init1 ldx #$00 ;find free IOCB ?c lda icchid,x cmp #$ff beq ?f txa clc adc #$10 tax bpl ?c ?f lda #<cfg ;try opening D:FOO.BAR sta icbufa,x lda #>cfg sta icbufa+1,x lda #$04 ;for reads sta icax1,x lda #$00 sta icax2,x lda #$03 jsr _xciov lda #$0c ;close jmp _xciov cfg .byte "D:FOO.BAR",$9b .org $02e2 .word init1 ; RUN SEGMENT .org $4000 run ldx #<txt_ok ldy #>txt_ok jmp putline txt_ok .byte "Started OK",$9b .org $02e0 .word run sd32.mae sd32down.obj Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 22, 2020 Share Posted February 22, 2020 Why would the Dos think the load has finished after the second Init segment? The only condition for that should be EOF. Also (and 30+ years too late to complain) it's a bastardisation of the standard to assume the load address as Run address unless overridden within the file. Another querie - if the first segment of the file is to populate the Init address, does SD 3 assume that to be the run address? ie, JMP $2E2 at EOF Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 22, 2020 Author Share Posted February 22, 2020 3 hours ago, Rybags said: Why would the Dos think the load has finished after the second Init segment? The only condition for that should be EOF. Because of the internal confusion. My current hypothesis is that the internal DOS parameters for the file being opened within the init segment ("D:FOO.BAR" in the example above) influence (or override) the internal DOS parameters for the binary file being loaded. Therefore if "D:FOO.BAR" exists and has been read out, an EOF status was reached, but the binary loader thinks that this EOF was reached in the binary file, hence it attempts to run it. When the "D:FOO.BAR" does not exist, the file is apparently internally marked as "not open", the loader trying to continue with the binary file gets an error 135, which is apparently so unexpected as to cause the DOS to crash. 1 Quote Link to comment Share on other sites More sharing options...
Rybags Posted February 22, 2020 Share Posted February 22, 2020 Could it be related to memory config, ie how many drives and buffers etc are allowed? Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 23, 2020 Author Share Posted February 23, 2020 I do not know. But even if so, one would then expect error 161 (too many files open) and not a crash... Quote Link to comment Share on other sites More sharing options...
Kyle22 Posted February 24, 2020 Share Posted February 24, 2020 Konrad, I am still having error problems w/ 4.49d. I am running a 65c802 in an Incognito. I now work 7 days a week (because now I am 50% owner of the store) :) so I don't have much extra time these days. I will install it again and do more testing and report results. IIRC, is was an error 146 Function not implemented when I had the error. 4.47 doesn't make the error, and 4.48 won't run at all because I don't have high RAM (Not possible on 802). Quote Link to comment Share on other sites More sharing options...
drac030 Posted February 24, 2020 Author Share Posted February 24, 2020 Kyle, as I told you, despite the 4.47 supposedly working, this looks like a hardware stability problem. Whether this is true or not, I cannot diagnose anything overseas without sufficient information. So: 1) first of all, to eliminate a hardware problem, please reproduce your exact setup on Altirra and report back, if the same problems occur there. This will prove, that the problem is in the software (and software can be fixed). By exact setup I mean the CPU (65C816+"High memory: none, 16-bit addressing" is 65C802) and the RAM config, the contents of the ROMs, the storage type, the disk contents, the DOS setup (config.sys and startup files) you use daily. 2) when you manage to reproduce the problem in this environment, please: a) specify the hardware config. b) specify all the resident drivers you use: file names, length of these files, time/date stamps on them. c) quote the CONFIG.SYS file(s) you use and other startup files (like AUTOEXEC.BAT). d) provide information, do you use TD.COM or not. If so, do the problems occur without. Thanks. 1 Quote Link to comment Share on other sites More sharing options...
Marius Posted February 24, 2020 Share Posted February 24, 2020 Today I sent Stephen J. Carden an e-mail. I hope he will check that, and return to here. He is one of the people who could address this issue. Quote Link to comment Share on other sites More sharing options...
Stephen J Carden Posted September 10, 2021 Share Posted September 10, 2021 On 2/21/2020 at 7:22 AM, drac030 said: Not sure if this is a bug in SpartaDOS 3 or maybe a misconfiguration (but I have no idea how to fix it in the latter case), but here is what I stumbled upon some day: I have a binary program which consists of several init segments and one run segment. This program loads fine and works under DOS 2.5, DOS XL 2.30, MyDOS 4.55p, BW-DOS 1.30 and, last but not least, SpartaDOS X. But with SpartaDOS 3.2d, 3.2g and 3.3a there is only a less or more spectacular crash during loading. I have found out that this crash occurs, because after the second init segment SpartaDOS 3 thinks that the loading is finished, thus (since the run vector has not yet been set at this point) making a call to the "beginning of the program", i.e. the first init segment, which at this time is of course long non-existing. Now the second init segment opens and parses a configuration file. And this - particularly the OPEN call - causes all this confusion. The file does not even have to exist: it is enough to make an OPEN 4,"D:FOO.BAR":CLOSE in an init segment to trigger this problem. If this is not fixable in a simple manner (like by changing a default parameter in SpartaDOS binary), I would say that this looks like a flaw disqualifying SpartaDOS 3 as a DOS. For opening a file during loading a binary is to my knowledge in no way a forbidden operation. And even DOS 2.5 tolerates this well. Hi All. This is not any code I have written. I need some one to send me the program so I can see what it is trying to do or if it is a virus program. Also Because of lance ringquest I do not support any version of SpartaDos 3.3 a,b,c,d. My Ramdisk programs and tdline2 will work with all versions of spartaDos I have been a bit sick lately but I do have some cool stuff for realdos on its way. Take care Steve Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 10, 2021 Share Posted September 10, 2021 Konrad has provided everything you need above (examples, source code, etc). Quote Link to comment Share on other sites More sharing options...
Stephen J Carden Posted September 23, 2021 Share Posted September 23, 2021 On 2/22/2020 at 1:30 PM, drac030 said: Because of the internal confusion. My current hypothesis is that the internal DOS parameters for the file being opened within the init segment ("D:FOO.BAR" in the example above) influence (or override) the internal DOS parameters for the binary file being loaded. Therefore if "D:FOO.BAR" exists and has been read out, an EOF status was reached, but the binary loader thinks that this EOF was reached in the binary file, hence it attempts to run it. When the "D:FOO.BAR" does not exist, the file is apparently internally marked as "not open", the loader trying to continue with the binary file gets an error 135, which is apparently so unexpected as to cause the DOS to crash. Hi all! Once again why are people loading and running this file when it is a problem file. This is not a program I have written. I have no idea where it comes from. But the program name means F*cked up beyond all recognition. That is what foo bar means. Draco was kind enough to turn it back into source. This kinda of crappy programming is why all my new stuff has a header section that tell a bunch about all my support program. The update I am working on will include a way to set and/or check a crc of any of my support program. I am writting a program what will allow the the end user to set a few function like displaying certain text out of a program. I am also removing lance ringquest out of all my programs. I just want to get back and update a few things with the support files. I have also received emails wondering if I am competing with sdx which I am not. SDX being a cart dos has a place for all. just like RealDos, MyDOS and all the other DOS's have there place. Most users do not know That I donated hardware so it would be supported with SDX. For the most part RealDos does everything I need. but I still have my hardware that has SDX Carts in them. I have some cool support files coming. Every One Take care and have a great Day! Stephen J. Carden Ph.D Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 23, 2021 Share Posted September 23, 2021 3 minutes ago, Stephen J Carden said: Once again why are people loading and running this file when it is a problem file. This is not a program I have written. I have no idea where it comes from. But the program name means F*cked up beyond all recognition. That is what foo bar means. F*cked Up Beyond All Recognition = FUBAR, not FOO.BAR. Foobar is a placeholder in computing: Foobar 5 minutes ago, Stephen J Carden said: This kinda of crappy programming is why all my new stuff has a header section that tell a bunch about all my support program. The assertion is that there is no reason why a perfectly well-behaved application should not want to open a secondary file on another channel as part of its initialisation process, before the binary load has completed. If the DOS binary loader disallows this or - as is the case with Sparta 3 and derivatives - becomes confused as a result, then it is DOS, not the binary file, which exhibits 'crappy programming'. The easiest solution would be to fix the issue in DOS. 2 Quote Link to comment Share on other sites More sharing options...
+Eyvind Bernhardsen Posted September 23, 2021 Share Posted September 23, 2021 2 hours ago, flashjazzcat said: F*cked Up Beyond All Recognition = FUBAR, not FOO.BAR. Foobar is a placeholder in computing: Foobar Quote It is possible that foobar is a playful allusion[2] to the World War II-era military slang FUBAR (Fucked Up Beyond All Repair).[2] Fun fact: both "foo" and "bar" are banned in Microsoft source code (along with lots of other controversy-adjacent terms). 1 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 23, 2021 Share Posted September 23, 2021 (edited) Mr. Carden may have had a memory lapse, he's used such conventions before at least in conversation. Please be kind. Many of us have the same kind of issues. I ask you remind and be kind. We still have much to offer. Edited September 23, 2021 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted September 23, 2021 Share Posted September 23, 2021 Is there evidence of unkindness in any of the above responses? I'm not entirely sure how I can participate in a discussion without presenting a point of view. 2 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 23, 2021 Share Posted September 23, 2021 (edited) I'm super guilty of this myself... It's a tone thing... and perhaps I am being to touchy. Sometimes getting direct and to the point is too terse, or sometimes stream of consciousness rambling makes it come off wrong. There is nothing wrong in the plain truth of the responses. But maybe just prefacing it with a little qualifier of some kind can help keep the usual pile on that generally occurs and even I participate in from happening. I know he means well as do we all. It's a hope to keep it from going wrong is the thing. I do understand where the crappy programming statement comes from though(in the response)... I agree with darn near everything you have said. as I read responses from folks I tend to combine them as a direction of the whole conversation these days and re-attribute bits of each to all in the conversation as a slope towards whatever it became. Sometimes I see this in my own posts and think that if someone hadn't built on my post it wouldn't be taken the wrong way. I also find that my building on another persons post can do the same. I just saw it possibly becoming a pile on and jumped in hoping to head it off at the pass. Good to see Stephen back on AA and hope he gets back into the groove and catches up on the forum. Great to see the clarity you bring as well FJC. Edited September 23, 2021 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
drac030 Posted September 23, 2021 Author Share Posted September 23, 2021 4 hours ago, Stephen J Carden said: Once again why are people loading and running this file when it is a problem file. (...) Draco was kind enough to turn it back into source. The source code presented in post #3 is an extract - in source form - from a larger program of mine, and the result of my debugging, why that program crashes badly while being loaded under SpartaDOS 3 and derivatives, whereas in the rest of the DOS-es listed it loads and runs fine. The listing pinpoints the exact code which causes the crash (in init1), and, because that code seems completely legit, the cause of the crash must be a problem inside SpartaDOS 3 binary loader, which goes bananas when an init segment is doing an OPEN call to the CIO. It may be actually very simple to fix, e.g. perhaps some internal channel number should get preserved across a call to jmp ($02e2). I know that people have teh SpartaDOS 3 source, and Real.DOS has its active developer, so this could get fixed. That is why I posted this, just as a bug report. 3 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.