couldn't it break existing installations that use, say, "mysqld.exe was started without parameters" ?

What is the benefit for removing the options ?
Just because mysql_install_db can do it, doesn't mean that they should be removed (as some users may still use the old options)

serg, mysql_upgrade_service would take care of that, iirc already does.
monty, we do not package prebuilt datadir anymore, and do not have any other tool that does bootstrapping, other than mysql_install_db.exe . So "--install" just does not work . Also it did extremely trvial stuff that sc.exe was capable of, since maybe Windows 2000, or NT.

Besides, "mysqld --install" would run service as LocalSystem account, the most powerful Windows account, comparable to Unix root, which is a security problem. mysql_install_db,exe, on the other hand, makes mysqld run under the least privileged Windows service account NetworkService, and it has to set the ACL of the datadir explicitly to make files writable for NetworkService.

I agree with "mysqld.exe --remove myservice" which can be replaced by the Windows command "sc delete myservice", but I absolutely don't agree with the removal of "mysqld.exe --install-manual myservice" that nothing replaces at the moment.
You say that mysql_install_db.exe and/or mysql_upgrade_service.exe are the replacement tools for "mysqld.exe --install-manual myservice", let me doubt it!
Can these tools only install a service without creating datadir and without creating a my.ini file?
Can these tools do exactly the same thing as :
mysqld.exe --install-manual wampmariadb64 --defaults-file=E:\wamp64\bin\mariadb\mariadb10.5.4\my.ini"

Otomatic - Dominique Ottello
Wampserver Developer

Otomatic. "sc create" can do this, can't it? Here is an old post of my colleague Chris
https://www.chriscalender.com/create-mariadb-windows-service/

The question is why do you want to run server without data directory. How do you bootstrap (create system tables), with the good old way?

sc create wampmariadb64 binPath="E:\wamp64\bin\mariadb\mariadb10.5.4\bin\mysqld.exe --defaults-file=E:\wamp64\bin\mariadb\mariadb10.5.4\my.ini"
creates the service, apparently with the same parameters as via mysqld.exe --install-manual, but the service won't start.

Did you read that post attentively ?

You need to add service name at the end of binPath

"E:\wamp64\bin\mariadb\mariadb10.5.4\bin\mysqld.exe --defaults-file=E:\wamp64\bin\mariadb\mariadb10.5.4\my.ini wampmariadb64"

How do you think server would know that it is started as which service? It derives it from the last command line parameter

data directory is created when installing different versions of MariaDB and, to switch from one version to another the actions are :

• Stop service version A
• Deleting service version A
• Create service version B
• Start service version B

Why do you delete and recreate the service ? What's the point?

I didn't read the message "attentively" because it was changed after I read it...

After rereading, this:
sc create wampmariadb64 binpath="E:\wamp64\bin\mariadb\mariadb10.5.4\bin\mysqld.exe --defaults-file=E:\wamp64\bin\mariadb\mariadb10.5.4\my.ini wampmariadb64"
works well.

> Why do you delete and recreate the service ? What's the point?
Because they are different versions of MariaDB and the installation paths of these versions are different.
For example, currently I have five versions of mariaDB: 10.1.45, 10.2.32, 10.3.23, 10.4.13, 10.5.4 and to switch from one version to another it is necessary to recreate the service that always has the same name.

I meant, reading "Chris' blog post" attentively . this blog post has not changed since 2012. It describes the very same problem you just had, gives an explanation, why binpath should add the servicename at the end.

Also note you can't always switch versions by simply restarting with new executables. if you upgrade from 10.4 to 10.5 for example, you need to stop the server with "innodb slow shutdown" (--innodb-fast-shutdown=0), and you likely need to run
mysql_upgrade after major version switch for system tables upgrade.

And mysql_upgrade_service takes care of all that, given that executables for the new version are in a different path. and of course, it also takes care of changing service's binPath.

So, would it be correct to state that you were requesting that "mysqld --install" should continue to live, to manually / partially replicate the logic of mysql_upgrade_service? Why not just to use mysql_upgrade_service as-is?

> Why not just to use mysql_upgrade_service as-is?
Because:
E:\wamp64\bin\mariadb\mariadb10.4.13\bin>mysql_upgrade_service --service=wampmariadb64
FATAL ERROR: Not a valid MySQL service

E:\wamp64\bin\mariadb\mariadb10.5.4\bin>mysql_upgrade_service --service=wampmariadb64
FATAL ERROR: Not a valid MySQL service

While it works perfectly for more than fifteen years with mysqld.exe --install-manual and --remove for MariaDB from 5.5.62 to 10.5.4 and for MySQL from 5.1.72 to 8.0.20

Your solution or upgrade just does not work, on the reason outlined above.
If you want to file a bug for mysql_upgrade_service, I might happily accept it. Or, you can try to replicate whatever mysql_upgrade_service is doing, poorly

Done in MDEV-23043