Hey I can only run pkgtool as root. So if I get the Slackware wine 9.58 package I install it as root. But then I can only execute wine if I'm root. How do I make wine available for non-root users?

There are several reasons why this could've happened; If you downloaded from linuxpackages.org, maybe the package has an issue, or if you compiled yourself there may be other stuff involved. Now, a self-compiled package should show up like:
-rwxr-xr-x 1 root root 2021120 2007-02-26 15:36 /usr/bin/e16
for instance (I don't have wine on this box, but e16 is something I compiled myself and use for real);

I don't know what's your level of knowledge either, so let's take it from the basics:
should return something like /usr/bin/wine or /usr/local/bin/wine something like that. You may even have several outputs, or the main one being a link, here follows a sample with the Gimp:
I found Gimp! Good! let's check permissions:
Oooops, it's a link, it isn't the real stuff: noticed the -> gimp-2.4 thingy? Let's try again with the link's target:
gotcha!
now for the actual check, let's list (ls -l) its properties:
So far, so good with my gimp at least: noticed the three X's? They mean Owner, Group AND Anybody can eXecute the application; If your wine looks like
then you miss this feature, and you must do:
&&

check that the x-for-execute parameter has been passed by doing

[a folder's name starting with a . is an invisible folder, don't forget to tick "show invisible folders" in your filebrowser of choice!]

Now issues with wine involves the fake C drive and where it's located; if your wine install failed to create a .wine directory in your end-user (non-root) home folder, then again there's a problem with the way wine installed itself; the poor hacker's way of dealing with that would be to, as root, copy this .wine folder from the root folder into the intended home account, and then do something as root like:
To try it out, just browse your .wine folder to find notepad.exe and try to fire it up with either the proper command line like
or right-click-select "open with" if you are in konqueror, and even sometimes double-clicking does it (well, not for me on my Fedora workstation but others seems to be more lucky than I am).

This way you'd be sure your wine is sane from a non-root user' perspective, and you can start fighting your way trough making exe apps actually working on your 'Nix box. A general recommendation of me: do it all from within this .wine folder, copy your executables at the right place inside the fake ~/.wine/c_drive/... in a micro$oft way, including the installers for bigger softs: that is key to eliminate the "where can wine work/how make the soft believe it's in a win-box" issue. Again, that is key: your wine install may be good, but you are forced to go root because your are not working from the proper location & need to be root-ed to... be able mess around your entire hard drive!

Cheers.
If this was completely unusefull because far too obvious for you, well, sorry then, and let's say it may be worth reading for someone else with less experience

I think that you have to run wineprefixcreate first as non-root but I'm not completely sure if this can be the solution

and winecfg too... first of all actually, or so I believe but it's been a loooong time since I set up my fedora box I must say...

I've been succesfully using slackBuild scripts from slacky.eu site to build my own Wine packages for a long time.
It takes appr. one hour to produce a fresh package.
I did't encounter any serious problems going that way.
After upgrading or installing the package do not forget to clean a /tmp/ subdirectories used to compiling Wine and after that jump back to user account and invoke:

wine notepad.exe

to create ~/.wine subdirectory.

It is desirable to put some popular Windows *.ttf font files into ~/.wine/drive_c/windows/fonts directory.

As a side note, it is important to make sure your 'umask' setting is 0022 -- if it's not, the permissions will be screwed up (and will probably mess with your system's permissions too). I always build packages using the command `su -c umask 0022 && ./package.SlackBuild` (I basically always use SlackBuilds, whether I write them myself or use others' SlackBuilds). This shouldn't affect a default setup, but I have my user's umask set to 0077 so only I may read my files (not that anyone else uses this PC, but oh well). However, this doesn't appear to be your problem since you didn't say that your entire system was messed up. Run `winecfg` as your normal user (I think) and *hopefully* that will clear stuff up. I agree with the above posters in that you should try and run all Windows programs from within the '~/.wine/drive_c' directory.

Good luck.

Slackware packages are *supposed* to be installed as root. There's a VERY good reason that root privileges are required to write to the system as a whole.

If you can't execute wine as a normal user, then either your system is in bad shape, or the package you installed is bad. A good system with a good wine package will work just fine.

Just a thought -- if you got it from linuxpackages.net, which is notorious for having poorly created packages, the permissions or ownership of the wine files may be screwed up (maybe the root directories like /bin, /usr, etc are fine but the ownership of the wine files are set to an owner on the packager's PC...or something stupid like that). Take a look at the permissions for sure and it'll tell you what went wrong (take a look at the permissions for /bin, /usr, /etc, etc. to make sure they weren't screwed up as well).

Wait, if linuxpackages.net has poorly created packages then who has good ones? For Slackware.

slackbuilds.org
alien bob's repository
slacky.eu

I won't say linuxpackages.net has poorly created packages only ... the problem with it is that its package review is bad .. anyone is able to upload packages ... but there are quite a few people who upload packages to linuxpackages.net which are really good ... just make sure to check the package creators name.