What was wrong with the Amiga 1000/500/2000?

[Tomislav]

AmigaDOS wildcards: https://eab.abime.net/showthread.php?t=10065

[litwr]

Originally Posted by roondar

It works on the A500 too. But then, I don't try to read from restricted hardware resources while the OS is up.

What does work on the Amiga 500 (with WB 1.3) too? The timer reading with long intervals? No it doesn't. You know this. You have written about restricted hardware resources but what document listed the timer among them?

IMHO you like generalizations but good practical rules are rather a set of exceptional cases than just one common case. Nothing is wrong in reading a timer value, it mustn't affect the system normal functioning. Indeed if the timer is overtly used by the system it must be documented but in our case we don't have any Commodore documents (or at least I don't know such documents) where it was declared that the timer is restricted. So it was rather a quirk of WB 1.x which was fixed in KS 3 and maybe even in KS 2.

Originally Posted by roondar

No, we don't need to know that. What we need to know if why you feel that programming a computer with a real multitasking operating system as if it's really just a souped up C64 (i.e. pretending there is no OS) constitutes a "quirk" of the system. As opposed to it being something you decide to do that doesn't work properly on any multitasking operating system. You can keep pretending that it's a problem with the Amiga, but the only problem here is your refusal to use the system as intended. Either kill of the OS and access the hardware directly, or use the OS. There are no valid other options.

Your logic might be correct only if later Kickstart ROM didn't fix the problem. You again try to use only common rules but in practical programming exceptions are quite often. Nothing directly forbade us to read the timer.

Originally Posted by roondar

Sheesh. What's next, a quirk of the OS is that accessing the Blitter directly will likely crash the system? Because that's the exact same thing as what you're doing, just a different hardware resource. By this standard Windows 10/Linux are horrible systems, you can't directly access any hardware on them without running into problems.

You have used a very important keywords different hardware resource, thank you. Different hardware resources are treated quite differently. For example, it is quite normal to read and write video memory directly from an application program. The timer and blitter are different hardware resources.

Originally Posted by roondar

AFAIK it's in the Amiga DOS manual, but it's been long time since I read that so I could be misremembering. Besides, it took me all of five minutes to figure it out. This happens a lot with your problems with the Amiga on this forum: you do things the way you expect them to be (such as with the timer) and then complain that it's different from what you expect. Often seemingly without doing any research or even just asking questions ahead of time whatsoever. This really sounds more like a problem on your side rather than any system issue.

Excuse me but I must tell you the truth now, your help in this particular case about problem with CLI variables is worth almost nothing. Only Thomas helped me to understand it. I checked WB 1.3 manual it didn't provide the information which Thomas shared with us. I can also repeat that popular books about Amiga DOS also evaded this subject, I gave you examples. Why have you just ignored them?

Originally Posted by roondar

Note here that at least two of the problems/quirks on your list are issues I've never heard anyone else complain about - and I've been reading mailing lists/news groups/magazines and forums about the Amiga for around 30 years now. Also note that at least one of them has been denied to be true by several other users, but you keep claiming it's a thing anyway (the return code stuff).

You are still terribly wrong about this issue. It seems working with return codes is still a pain for anybody who tries to do some CLI scripting. It is very odd that it was not fixed even in WB 3. You have read your sources rather superficially because there are several tools which people had to create to handle this issue. Check for example, CheckRet utility on Aminet. It was written in 1993, a man cannot wait more time in hope that a standard way appeared. Check for another example, JMenu utility which like many other such utilities had to use an environment variable setting instead of using a return code.

Originally Posted by a/b

He doesn't understand the difference between system calls/functions and shell commands.

What allows you to make such a rather offensive claim? I am quite experienced in modern shells and know how old DOS worked.

Originally Posted by a/b

Makes uneducated and bogus claims and then fabricates conslusions.

Please be more specific. IMHO your reaction has been very odd. I just make a list and we can discuss it. You, of course, can send me a private message if you need some more clarifications.

Originally Posted by idrougge

You should keep in mind that from AmigaOS 2.0 onwards, ARexx is part of the system.

Shell scripts are awful on all operating systems, and AmigaOS has avoided going down the ill-advised path of implementing a really bad programming language in its shell, like Bash, by integrating a proper programming language instead.

That also means that the primitive Ask command can be left as is, since if you need more features than that, you have ARexx at your disposal.

You are right. Arexx is good. But it appeared only in 1990. We are discussing issues of the first Amigas. However Arexx has not replaced CLI shell completely. So issues of CLI remain actual despite the presence of Arexx.

Originally Posted by Bruce Abbott

I run my A1200 into a TV through the composite output and it's fine. I use it for everything from web browsing to programming to playing games (even Doom!). Ham8 images are awesome in composite!

It is really interesting how an old analog TV could show Amiga hi-res screen, for example 640x480. IMHO letters become indistinguishable in such mode. And the A1200 can use higher resolutions. Sorry I still can't understand how it was possible.

Originally Posted by roondar

This one also confused me quite a bit. I actually coded directory trawling code on a number of different systems (Linux, Unix, Windows NT/2000/XP) and last time I still did that (circa 2005-2006), I don't recall even single one of them that allowed the use of wildcards in their system functions. They all expected you to loop through with some sort of examine/get next to examine loop. Through the shell/command line, sure you could use wildcards. But not through the OS functions.

It's possible that has changed by now, but it was the normal state of affairs back in the day.

Yes. Unix shells do all pattern expansion before a program call. However in MS-DOS (and you mentioned Atari DOS) system functions accepted patterns. So it seems that earlier Amiga CLI works like MS-DOS for this case and the later like Unix shells. It was the main source of my big confusion around this matter. Thank you very much again for your help.

Let's try to think around a practical task. For example, an application program needs to have a way to handle a user input which enters some filename pattern. This program has to show the user all files matching his entered pattern. I don't know any way how to program this task in WB 1.x, but write functions which will do the pattern matching. WB 2 provides us with such functions.

Originally Posted by AmigaHope

What's weird here is listing OS issues as tied to a hardware model. From an operating system standpoint the A500 and A1200 are near identical. The only difference is due to driver issues you can't really run AmigaOS 1.x effectively on the A1200 since drivers are missing for stuff like the IDE controller.
Nothing ties you to 1.x on the A500. AmigaOS 3.x runs just fine on it.

There is such thing which we call nostalgia. I am sure a lot of ppl (me included) continue to think about the Amiga because it helps to remember times when they were younger and better. My Amiga had WB 1.2 so I am a bit stuck in older KS and WB.

Originally Posted by Bruce Abbott

SASC too.

void chkabort(void) ; 
void Chk-Abort(void) ; 

This code replaces the function normally called for a Control-C with a 
function that does nothing.

It is interesting. Does it mean that the poor resource tracking is not an actual issue in WB? Anyway this thing can work only with CLI programs.

Originally Posted by Tomislav

AmigaDOS wildcards: https://eab.abime.net/showthread.php?t=10065

We are discussing how to use wildcard patterns inside application software.

[roondar]

Originally Posted by litwr

What does work on the Amiga 500 (with WB 1.3) too? The timer reading with long intervals? No it doesn't. You know this. You have written about restricted hardware resources but what document listed the timer among them?

Yes, the A500 does support this. I and others told you how and why this is the case already, I'm not going to repeat it. As for which document tells you not to use hardware directly, the Amiga RKM (which is/was the official OS documentation for developers) does this in several places. Here's two of the more relevant quotes from the introduction chapter of the book:

Originally Posted by Amiga RKM manual

What Every Amiga Programmer Should Know:

The Amiga is a multitasking computer. Keep in mind that other tasks are running at the same time as your application. Always ask the system for control of any resource you need; some other task may already be using it. Give it back as soon as you are done; another task may want to use it. This applies to just about every computing activity your application can perform.

* Never assume that programs can access hardware resources directly. Most hardware is controlled by system software that will not respond well to interference from other programs. Shared hardware requires programs to use the proper sharing protocols. Use the defined interface; it is the best way to ensure that your software will continue to operate on future models of the Amiga.

Note here that this tells you that you can't access any hardware resource directly. This, wouldn't you know it, includes the hardware timer.

IMHO you like generalizations but good practical rules are rather a set of exceptional cases than just one common case. Nothing is wrong in reading a timer value, it mustn't affect the system normal functioning. Indeed if the timer is overtly used by the system it must be documented but in our case we don't have any Commodore documents (or at least I don't know such documents) where it was declared that the timer is restricted. So it was rather a quirk of WB 1.x which was fixed in KS 3 and maybe even in KS 2.

Except the document I listed above (and that's just the official documentation), which tells you you can't access any resource except through "the defined interface", which certainly is not directly reading through the hardware.

Note here that this "rule" is not just spelled out in the official documentation. For fun, I checked out the only two remaining paper non-official books I have on Amiga programming. Those are Amiga Intern 2.0 and Amiga Machine language. As expected, both of these books tell you not to access the hardware directly in chapter 1. Now, only one of these books I have is in English, so let me just quote from that one:

Originally Posted by Amiga Machine Language, page 12

There is another restriction regarding multi-tasking that applies to assembler programmers. Aside from the use of extra memory, which must first be reserved, the hardware registers should not be directly accessed. Instead, the library functions should be used.

Note here that the hardware timer is accessed through hardware registers. Really, this is such common knowledge and repeated so often that I can't even fathom why you think denying it will change anyone's position here.

Your logic might be correct only if later Kickstart ROM didn't fix the problem. You again try to use only common rules but in practical programming exceptions are quite often. Nothing directly forbade us to read the timer.

Apart from the official and unofficial programming guides for the system of course. The OS change is irrelevant as on later KS roms you're still not supposed to do this. I.E. it works by accident in later versions, not by design.

Edit: I changed the above section to be more clear.

You have used a very important keywords different hardware resource, thank you. Different hardware resources are treated quite differently.

Not on the Amiga (or in fact any multitasking OS), where the official developer documentation explains that doing this kind of stuff will lead to problems. Try directly writing or reading from video memory on Windows 10 without going through the OS first to get the appropriate access and tell me how it goes.

Excuse me but I must tell you the truth now, your help in this particular case about problem with CLI variables is worth almost nothing. Only Thomas helped me to understand it. I checked WB 1.3 manual it didn't provide the information which Thomas shared with us. I can also repeat that popular books about Amiga DOS also evaded this subject, I gave you examples. Why have you just ignored them?

That's funny, because I just looked up my copy of the AmigaDOS 1.3 User Manual (in Dutch) that I got with my A500 and checked. And what do you know, it tells you that the IF command can use variables using $ (see chapter 2-20). It also tells you what GETENV (chapter 2-18) and SETENV (chapter 2-36) do. So the information on how to set and use environment variables is part of the official documentation. Who knew

Be honest here: have you actually read any of these books?

Edit: I have checked your sources because I found it hard to believe this. The AmigaDOS inside and out book does mention environment variables, though I'll admit they don't give a clear example (which is the book's fault and not the OS's fault). Regardless, their descriptions of GETENV/SETENV as well as IF all mention the use of variables. The linked German Amiga DOS 1.3 manual also mentions them. The description for IF for instance states: "Der Befehl IF ist in der Lage, Umgebungsvariabelen zu vergleichen. Soll eine Umgebungsvariabele angegeben werden, ist vor dem Namen der Variablen das Zeichen $ einzugeben" (page 2-21).

This all further makes me doubt you actually read and/or understood these books.

You have read your sources rather superficially because there are several tools which people had to create to handle this issue.

That's a rather rich claim coming from someone who doesn't know what the Amiga DOS manual states, doesn't know what the RKM states and denies that common knowledge presented in numerous books (including official documentation) on Amiga programming is valid.

Anyway, the example CheckRet actually supports what I said - if the OS doesn't support return codes other than 0,5,10 or 20 then that is a totally superfluous command to have. Also note here that the command FAILAT can accept any return code, including numbers over 20 (the example in the Amiga DOS manual with my A500 actually uses FAILAT 25). The confusion here is that you're mistaking the IF functions built in condition checks with the OS supporting only certain options.

Edit: note here that the long-form Amiga DOS manual (which the short form one you and I have refers to all the time) makes it clear that the IF flags trigger if the return code >= 0,5,10 or 20 and not = 0,5,10 or 20. This means that a program that returns with a return code which is not 0,5,10 or 20 can be detected through IF.

Let's try to think around a practical task. For example, an application program needs to have a way to handle a user input which enters some filename pattern. This program has to show the user all files matching his entered pattern. I don't know any way how to program this task in WB 1.x, but write functions which will do the pattern matching. WB 2 provides us with such functions.

The naive way to support this if you really can't be bothered to find another way is to call the DIR command from the application with the wildcard supplied and route the output into your program.

However, normally I'd suggest using a file requester instead. These do the hard work for you. There's several options for this, ARP was probably the most popular. But if neither of those takes your fancy then you'll indeed have to write your own functions.

[idrougge]

The return code of the last command is always in the RC variable and can be checked as any variable; or was this not in place in 1.3? Sounds unlikely.

[roondar]

Originally Posted by idrougge

The return code of the last command is always in the RC variable and can be checked as any variable; or was this not in place in 1.3? Sounds unlikely.

I tested this and $rc works in KS2.0+. It can be used with the IF command to allow for any return codes to be checked. However, it does not work under 1.3.

[litwr]

Originally Posted by roondar

Apart from the official and unofficial programming guides for the system of course. The OS change is irrelevant as on later KS roms you're still not supposed to do this. I.E. it works by accident in later versions, not by design.

It is just your assumption without the real proof.

Originally Posted by roondar

Be honest here: have you actually read any of these books?

I was confused by a fact that $ can only be used inside the IF-command. However AmigaDOS Inside & Out (1991) in Engilsh missed $'s completely. Anyway thank you but you can notice that my point had some basis too.

Originally Posted by roondar

Anyway, the example CheckRet actually supports what I said - if the OS doesn't support return codes other than 0,5,10 or 20 then that is a totally superfluous command to have. Also note here that the command FAILAT can accept any return code, including numbers over 20 (the example in the Amiga DOS manual with my A500 actually uses FAILAT 25). The confusion here is that you're mistaking the IF functions built in condition checks with the OS supporting only certain options.

Edit: note here that the long-form Amiga DOS manual (which the short form one you and I have refers to all the time) makes it clear that the IF flags trigger if the return code >= 0,5,10 or 20 and not = 0,5,10 or 20. This means that a program that returns with a return code which is not 0,5,10 or 20 can be detected through IF.

You can't distiguish more than five variants. How to choose one of the six variants? No way before WB 2. So CheckRet is quite useful for such cases.

Originally Posted by idrougge

The return code of the last command is always in the RC variable and can be checked as any variable; or was this not in place in 1.3? Sounds unlikely.

Thank you very much. I corrected my claim "3) no way to use program return codes, only few "standard" return codes are allowed (exactly 0, 5, 10, 20) until WB 2.0"

[Thomas Richter]

Originally Posted by idrougge

The return code of the last command is always in the RC variable and can be checked as any variable; or was this not in place in 1.3? Sounds unlikely.

Local shell variables (unlike environment variables) did not exist before Kick 2.0, so "no". They require an extension of the "process" structure Tripos did not have. The return code is instead placed in "CLI->CLI_ReturnCode" - pardon me "clip!cli_returncode" (as the CLI is in BCPL), and is available there. The CLI does check, though, whether the return code is above the critical fail level, which can be set by "FailAt" and fails if it is. So there is certainly more flexibility in the return codes than just the "if"-command.

[Thomas Richter]

Originally Posted by litwr

Thank you very much. I corrected my claim "3) no way to use program return codes, only few "standard" return codes are allowed (exactly 0, 5, 10, 20) until WB 2.0"

No, that's just blantly wrong. All return codes are allowed - nothing happens if you have any other return code - and you can certainly make use of them through "FailAt".

[roondar]

Originally Posted by litwr

It is just your assumption without the real proof.

Apart from the documentation I extensively quoted which shows you explicitly that you're not supposed to access the hardware directly and that doing so can cause issues of course

I was confused by a fact that $ can only be used inside the IF-command. However AmigaDOS Inside & Out (1991) in Engilsh missed $'s completely. Anyway thank you but you can notice that my point had some basis too.

No. It's in the manual and it's not exclusive to the IF command even under 1.3 (though it indeed only works with a few commands and not all commands). You really have no point, it always worked. You just didn't know this and assumed it therefore didn't. The clear lesson for you here is to ask first and only conclude/judge after understanding the answer.

You can't distiguish more than five variants. How to choose one of the six variants? No way before WB 2. So CheckRet is quite useful for such cases.

Only if you refuse to use other methods for dealing with this problem of testing multiple different output options. Just use an environment variable for menu's. It's much more convenient than this thinking style of requiring return codes for this purpose. It even allows for a more elegant system: use the environment variable for details and the return code for an overall status.

This would allow your menu program example to have infinite choices, while also having the option of returning a error/warning code separate from the menu choice.

Thank you very much. I corrected my claim "3) no way to use program return codes, only few "standard" return codes are allowed (exactly 0, 5, 10, 20) until WB 2.0"

Still wrong, as Thomas pointed out.

[Thomas Richter]

Concerning the '$', there are two places where it works. First, the "if"-command supports it natively, but there only provides access to environment variables. No other command expands the $. The execute command supports argument substitution, though in a patchy way. Thus, if you want to pass around arguments and make shell scripts depending on them, the only way would be through 'execute'.

The second place where $ works is within execute, but not for argument substitution, but for <$$>, i.e. it has a different meaning, in best (inconsistent) Amiga tradition.

[idrougge]

Originally Posted by Thomas Richter

Local shell variables (unlike environment variables) did not exist before Kick 2.0, so "no".

Just amazing how much is missing from earlier OS versions.

[a/b]

Originally Posted by litwr

It is just your assumption without the real proof.

That's very rich coming from you.

[litwr]

Originally Posted by Thomas Richter

No, that's just blantly wrong. All return codes are allowed - nothing happens if you have any other return code - and you can certainly make use of them through "FailAt".

By standard scripting means?

Originally Posted by roondar

Apart from the documentation I extensively quoted which shows you explicitly that you're not supposed to access the hardware directly and that doing so can cause issues of course

You changed the subject. It was about the correction in OS which stopped clear its timer since WB 2.

Originally Posted by roondar

No. It's in the manual and it's not exclusive to the IF command even under 1.3 (though it indeed only works with a few commands and not all commands). You really have no point, it always worked. You just didn't know this and assumed it therefore didn't. The clear lesson for you here is to ask first and only conclude/judge after understanding the answer.

You have written an oddity. The $-variables do not work with the echo-command in WB 1.3, we know this. So it doesn't work always. Thomas has written "No other command expands the $".

Originally Posted by roondar

Only if you refuse to use other methods for dealing with this problem of testing multiple different output options. Just use an environment variable for menu's. It's much more convenient than this thinking style of requiring return codes for this purpose. It even allows for a more elegant system: use the environment variable for details and the return code for an overall status.
This would allow your menu program example to have infinite choices, while also having the option of returning a error/warning code separate from the menu choice.

Indeed users had to use variables instead of return codes. It has been my point! So it is a drawback because they just couldn't use return codes. It was corrected in WB 2.

Originally Posted by a/b

That's very rich coming from you.

Would you like to clarify your point?

[robinsonb5]

Originally Posted by litwr

You changed the subject. It was about the correction in OS which stopped clear its timer since WB 2.

The point you're missing is that, provided the OS interfaces (i.e. timer.device and any other timing-related functions the operating system provides) do the right thing, what the OS does to the timer in the background is actually none of your business, or mine, or anyone else's. It can clear the counter ten times a second if it really wants to, provided the OS interfaces give correct results. It might be inconvenient, but it's not *wrong*.

The principle is very simple - while the OS is running it owns the hardware.

The published OS interfaces are a contract by which the OS pledges to behave in a certain way. You can make no assumptions about *how* the OS fulfils that pledge, and as you noticed, it will vary from version to version.

Your end of that contract, as a programmer, is not to touch the hardware, or make any assumptions about what the OS is doing with the hardware.

If you're not willing to abide by your end of the contract then you have to disable the OS. At that point you have full control over the hardware and can do whatever you want with it.

If the OS does things to the hardware that you're not expecting, even if it's only one particular version of the OS, it's fine to say "This is really inconvenient" - but it's not fine to say "There's a bug in this version of the OS", because at no point did the OS ever promise not to do the thing that's annoying you!

[roondar]

Originally Posted by litwr

You changed the subject. It was about the correction in OS which stopped clear its timer since WB 2.

No, it wasn't. It was about why your method for using the timer was and still is dead wrong. As several people, including me, have by now pointed out ad nauseam, your so-called drawback only exists if you use the wrong method for accessing the timer. Use the correct method and it works just fine.

Your assessment that OS 2.0 'corrected' this with the idea being you can just bang the hardware to access the timer is based on nothing. OS's change all the time, but what hasn't changed is the fact that Commodore has literally told you in their documentation that you can't access hardware directly and expect that to work while the OS is running.

You have written an oddity. The $-variables do not work with the echo-command in WB 1.3, we know this. So it doesn't work always. Thomas has written "No other command expands the $".

Your reading comprehension is failing you here. When I write "it always worked" while also writing just prior to that "though it indeed only works with a few commands and not all commands" I quite obviously am not claiming it works for all commands. I'm pointing out that, contrary to your original claim, variables actually existed in KS1.3 and therefore using variables was always possible. As for the number of commands, well - I already told you I'm not an Amiga DOS scripting expert. It doesn't change anything important about what I'm saying here, variables exist and can be used.

Not nearly for everything, but that is not needed to prove your initial point wrong.

Also, if you actually read up on how EXECUTE runs scripts in the full-length Amiga DOS manual, you'll see that there are ways to have the EXECUTE command do many of the things you might want to do with variables for you. I'm not sure if this info is also in the short-form manual, but check out pages 54 onwards from the Amiga DOS manual (1986, ISBN 0-553-34294-0) to see how you can do things like replacing parameters with defaults, etc.

Indeed users had to use variables instead of return codes. It has been my point! So it is a drawback because they just couldn't use return codes. It was corrected in WB 2.

Sigh. In other words: what you want to achieve is perfectly possible, but it doesn't work in the way you're used to, so it's wrong.

[duga]

Originally Posted by litwr

Yes, I had to buy a bulky device for this. However the color composite output is rather useless for AGA graphics.

If you were still using a TV as your monitor in 1992 or later then you at that time probably had a RGB capable SCART input in your TV (at least in Europe).

[idrougge]

I certainly didn’t, since the TV I was using was neither new nor fancy.

[roondar]

Originally Posted by idrougge

I certainly didn’t, since the TV I was using was neither new nor fancy.

The TV I used for my Amiga was barely holding together at the time, had to press the on switch on average six times before it worked

[dreadnought]

Same here, I actually started with a green monitor @@...Amiga & no colour...*shudder* Later on my persistent begging yielded a lil' 14" colour TV, but it was some no-brand clone with composite only.

I think RGB / SCART enabled TVs got bit more popular and affordable in the second half of the Nineties.

[litwr]

Despite all minor software drawbacks the Amiga offered a great environment for programming. WB CLI was like shells of modern Linux. Arexx was like Perl or even Python. GUI was also quite good. One can only wonder why Commodore didn't follow Apple methods and didn't attack the IBM PC? Apple had worse hardware and software and was quite successful. Commodore instead made a big useless "toy" of the Amiga and offered the "serious" Commodore PC.

Originally Posted by robinsonb5

The point you're missing is that, provided the OS interfaces (i.e. timer.device and any other timing-related functions the operating system provides) do the right thing, what the OS does to the timer in the background is actually none of your business, or mine, or anyone else's. It can clear the counter ten times a second if it really wants to, provided the OS interfaces give correct results. It might be inconvenient, but it's not *wrong*.

If the OS does things to the hardware that you're not expecting, even if it's only one particular version of the OS, it's fine to say "This is really inconvenient" - but it's not fine to say "There's a bug in this version of the OS", because at no point did the OS ever promise not to do the thing that's annoying you!

You still missed the point. WB1.3 periodically clears the timer. WB3 doesn't do it. So it is not a necessity to clear the timer periodically. Maybe that zeroing was a hidden OS bug. Anyway WB3 shows us that actually system doesn't need to clear the timer periodically. So it was a minor drawback of old WB or maybe rather just a little quirk. I didn't call it a bug.

Originally Posted by roondar

Also, if you actually read up on how EXECUTE runs scripts in the full-length Amiga DOS manual, you'll see that there are ways to have the EXECUTE command do many of the things you might want to do with variables for you. I'm not sure if this info is also in the short-form manual, but check out pages 54 onwards from the Amiga DOS manual (1986, ISBN 0-553-34294-0) to see how you can do things like replacing parameters with defaults, etc.

WB didn't have variables until 1.3 and support for variables in WB 1.3 was very limited. EXECUTE variables are not variables but parameters. They are better than nothing but they are not normal variables.

Originally Posted by roondar

In other words: what you want to achieve is perfectly possible, but it doesn't work in the way you're used to, so it's wrong.

So you have eventually agreed with me. Thank you.