The user login screen (sometimes referred to as the LoginWindow or greeter) in X windows is separate from the user's desktop (logged on session). There are many possibilities, so this outlines the basics for a reasonably new distribution running GNOME or KDE for a workstation (hard drive boots and runs the operating system). The general approach is to run the mytsoft process prior to the appearance of the login window.
For different window managers/display managers, the process which handles the login (startup/init/greeter) is different, and the configuration files and locations are different.
GNOME uses gdm - most likely script location is /etc/gdm/Init/Default
KDE use kdm - most likely script location is /etc/kde4/kdm/Xsetup (or /etc/kde3/kdm or /usr/kde/version/share/config)
others may use xdm - most likely script location is /etc/xdm/Xsetup

Steps
Step 1) Locate mytsoft executable - for example, perhaps /home/user/Downloads/my-t-soft/mytsoft
Step 2) Identify and using your favorite editor, open & edit the appropriate script for your system
Step 3) Each script can be different, and it is recommended that you add the following line towards the beginning (or top) of the script in case some logic exits or quits the script
/home/user/Downloads/my-t-soft/mytsoft &
(The ampersand is important as it loads the mytsoft process as a background process and does not stop the execution of the script)

Notes:

• This assumes that the system is configured for a graphical startup using X Windows (typically run-level 5)
• The display manager (gdm/kdm/xdm) may have options that can determine if the Default or Xsetup script are run (or if there are overrides)
• If SELinux is enabled (Security Enhanced Linux, e.g. Fedora, Red Hat, CentOS, etc.) you may need to specifically "allow" the execution of mytsoft, especially determined by location - see additional notes below.

SE Linux notes
In the above example, with SE Linux set to enforcing (e.g. /etc//selinux/config, SELINUX=enforcing), the execution of mytsoft may be blocked. You can test the configuration by setting SELINUX=disabled, and reboot - if it works in that configuration, but not with SELINUX=enforcing, then the following approach may work (if system configured correctly).
Logged in as root at terminal console:
[root]# audit2allow -a -M mytsoft
[root]# semodule -i mytsoft.pp
The above commands extract the audit log (/var/log/audit) to determine blocked execution, and creates a policy file (e.g. audit2allow), and then installs the policy file (semodule install)

The SE Linux concepts are complex, but here are a few more details that may help grasp what is needed - essentially if an operation is "denied", it must be explicitly "allowed" - the following is a human readable version of the policy (again, for the above example/location):
mytsoft.te - text file

module mytsoft 1.0;

require {
type user_home_t;
type xdm_t;
class file execute;
}

# xdm_t
allow xdm_t user_home_t;file execute;

To create the policy file, you may be able to use the selinux Makefile (depending on system configuration), e.g.:
[root]# make -f /usr/share/selinux/strict/include/Makefile mytsoft.pp
To check the built file before installing, you can use checkmodule, e.g.
[root]# checkmodule -b mytsoft.pp

To manually build the policy file from the .te file, use the following:
[root]# checkmodule -M -m -o mytsoft.mod mytsoft.te
[root]# semodule_package -o mytsoft.pp mytsoft.mod
[root]# checkmodule -b mytsoft.pp
[root]# semodule -i mytsoft.pp

Notes:

• Depending on product, release version, OS version, and specific technical issue, some tech items are very specific, and some may span to other products/versions
• Downloadable files can also be accessed by anonymous FTP at ftp://downloads.imgpresents.com
• Older files are moved into a separate archive location - see notes/details/new location in *.archived.txt text file

• Return to Technical Support

As seen in ...