then we have been talking about different things. 😀
you were talking about removing the == check from IF.
I supposed you wanted to do that to allow spaces for the first argument.
No, that's so it doesn't complain about spaces in the value, which is valid.
The error message, which I've commented out, isn't supposed to be there.
DOS 5.0 handles setting a variable with a value that has spaces, and doing an if empty check(if %var% == "") on a variable set to a value that has spaces.
There is no issue/contention/argument for/etc of spaces for the first argument.
It looks like a bit of a weirdness you are relying on. (At least in my opinion.)
1set VAR="a b" 2if %VAR == "a b" dir <-- no dir/error 3if %VAR% == "a b" dir <-no dir/error 4if "%VAR" == "a b" dir <-- no dir/error 5if "%VAR%" == "a b" dir <-no dir/error 6if NOT %VAR == "" dir <-gives dir 7if "a b" == "a b" <-syntax error 8if %VAR "a b" dir <- syntax error (omiting the ==)
So it only works for testing against emptiness, but not against the contents ?!
Apparently. Again, the diff doesn't change the handling, just got rid of the error message that was in the way and not supposed to be there, and what I did add, the arithmetic, doesn't touch anything, its handling is encapsulated.
I will see I can add support for that. I was planning on adding the set /a support. but i didn't like the removal of the == test as that is required, there is something else wrong apparently. I have to think about it for a while to see how to support that. (testing for emptiness on variables with spaces in them).
Here's handling until space or =, except spaces inside the variable.
1 // Word is until space or = 2 while(*args 3 && (!(isspace(*reinterpret_cast<unsigned char*>(args)) && ((*args+1) == '='))) 4 && (*args != '=')) 5 args++;
When I run the setup file for heroes of might and magic, it tells me the speed of my "cpu" in dosbox. I don't know how accurate it is, but I can sort of use it to gauge by.
Quick question: When I set a cycle amount, for example 20000, it tells me I have a 486 @ 425 mhz. No matter how high I set the cycles, it always detects a 486, even beyond 1500mhz. So my question is, would there be a theoretical difference in performance between, say, a 425 mhz 486 and a 425 mhz Pentium processor? Or put another way, if Dosbox emulated a Pentium processor at that speed rather than a 486, would there be an increase in demand from the host and/or an increase in performance?
help(-h, /h, -?, /? etc.) isn't working in the latest incarnation, so need to run the bug down.
Perplexia,
Always reporting 486@425MHz would be a limitation of the program's detection function. There is an actual difference between a 486 and Pentium at any speed. Some opcodes are faster on the 486, with the pentium faster overall. DOSBox emulating a Pentium would mostly mean handling the added opcodes. As has been covered, DOSBox doesn't track opcode cycles, opcodes are seen as opcodes, not 486 or pentium opcodes. There's likely more overhead to emulating a pentium, so there'd be an increase demand on the host. Programs that would use pentium opcodes, optimized for a pentium, emulation optimizations of the pentium handling, .. could see an increase in performance in spite of additional overhead, but overall likely no difference.
The original line "&& (!isspace(*reinterpret_cast<unsigned char*>(args)))" produces the string " == "-h" goto finish", having a space at the beginning.
// && (!(isspace(*reinterpret_cast<unsigned char*>(args)) && ((*args+1) == '='))) produces the string "== "-h" goto finish", without a space at the beginning.
The following stripspaces(args) gets rid of the leading space of the original line at which point they're the same.
The difference is what end_word1 is set to just prior to stripspaces.
end_word1 is a local variable of CMD_IF, its only references in all of DOSBox being inside CMD_IF, both the lines setting end_word1, yet it's being used as a global variable somehow somewhere, and it's where the help handling is breaking.
All I see here is the same result minus the function call overhead.
- char* woord2 = StripWord(args);
+// char* woord2 = StripWord(args);
+
+ char* woord2 = args;
+ // Word is until space
+ while(*args && !isspace(*reinterpret_cast<unsigned char*>(args)))
+ args++;
+ if (*args) *args++ = 0;
+ // 2nd word must terminated with space in msdos 5.0 but command line is trimmed in dosbox
+/* else {
+ SyntaxError();
+ return;
+ }
+*/
This is the fix, except it crashes which I haven't gotten around yet, and it doesn't handle variables with spaces, which it should.
the first one: it makes more then one NOT possible. if NOT NOT a==b (hence the has_not = !has_not )
the second one: StripSpaces isn't the same as read until a '='
Need to example the third and other parts a bit more closely though. There is just so much code snippets in this thread now.
I don't know how he arrived at 2nd word must be terminated with space, adding such would always make the strings not match. Testing DOS 5.0 shows this is incorrect, DOS 5.0 returns "Bad command or file name" if you try to compare with a trailing space(set val=word1; if "%val%" == "word1 ".) Top it off, such has nothing to do with his description of problem 8 on sourceforge, which is an issue with the handling of quotes on the left variable. I see nothing in the patch that fixes problem 8.
I'll take your word on the first, second isn't the same, but same result. I'm not sure what you mean with about the third. If you're asking me to clarify what I said, dosbox crashes, shutsdown, if either the third or fourth part is included, so I haven't tested as I haven't been able to run it. Looking at it I know it doesn't handle variables with spaces, as the while breaks on !isspace=false, so it will end the string on the first space it hits. The fourth, returns before comparing if woord2 is empty, thereby preventing empty check.
Last edited by ih8registrations on 2008-11-07, 12:39. Edited 1 time in total.