Reidyn

You won't be able to just "rpm -e ymessenger". The package name includes the "-1.0.4-1", so try "rpm -e ymessenger-1.0.4-1".

The safest way to do this is to tunnel through SSH. I do wish that I had time to detail the instructions for setting up an SSH tunnel for VNC, but there are a number of websites that will tell you how to do this. The key is knowing that ports 5900-5909 correspond to VNC session numbers 0 through 9. If you want to use session 1, you will need port 5901. In this case, just set up a tunnel on the client machine for port 5901, and then in VNC, connect to localhost:1 (or 127.0.0.1:1) and you should be all set. If you're not familiar with SSH tunneling, you should read up on how it works. You're basically making the client machine think that the services that are available at the other end (through the SSH) are actually on the local machine. Those requests are forwarded by SSH to whichever machine on the other end you want them to be forwarded to. All of this is fully encrypted via whichever encryption you're using in SSH (AES is excellent), and while you'll take somewhat of a performance hit through an encrypted connection, it is far safer than having this kind of traffic passing unencrypted over the internet. Good luck!

Get the XFT build of Mozilla. Search around on mozilla.org and/or mozillazine.org for a link to it.

Jimmijo, THAT'S the way to yank out the old moldy memories in a painful sort of way!! But if you really want agony, forget about the onboard sound and video... that's too much luxury in one machine. Maybe we would prefer an old 128k Trident ISA video card that you could never find stable drivers for, and any POS sound card from the now-defunct Reveal or any of the other crappy redistributors of the early 90s that had crummy SB emulation.

Regarding the indexing service, I agree. This has been a problem for me as well, easily corrected by disabling it.

I just used the iTouch utility to reconfigure the web browser button so that it runs the Mozilla.exe executable from the Program Files folder. It was pretty easy to change. I'm not at home, so I can't get detailed instructions on how to do that. At least now you have an idea of how to do it. Use the iTouch help if you need information about how to remap the buttons. You should also be able to find the command line arguments for making Mozilla open a specific web page so that you can map the other buttons to specific web pages. This was rather easy to do as well.

Backup your OE store folder by hand. To find out where it is, use the menu option "Tools / Options", then go to the "Maintenance" tab, and click "Store Folder...", then note the path that is shown. Just copy the entire folder to a safe place either through Windows Explorer or whatever backup program you are using. To restore it after an OS reinstallation, run OE once. Follow the same procedures above to identify the location of the new store folder. Exit OE. Using Windows Explorer, delete the contents of the newly created store folder. Either manually copy the contents of your backed up store folder to the new folder, or restore to that location using your backup utility. Run OE again, and you should find your messages intact. If you want to also back up your address book, you'll have to use "Find Files" on your start menu and look for "*.wab". You'll likely have one that is the actual file, and one that is a backup (it has a "~" in the name). You'll only need the original. Copy it to a safe place. When you've reinstalled the OS and run OE for the first time, search for "*.wab". Replace that one with your backed up copy, and rename the backed up copy to be exactly the same as the one that you are replacing.

That happened to me for one entire day. It worked fine the next day. Most likely it is the other end, not yours. Try again later.

Quote: Question 1: I never hibernate my computer, can i somehow deactive the 400mb hibefil.sys? If you aren't intentionally putting your computer into hibernation mode, then you don't need the hibefil.sys. Go into the control panel "Power Options" applet, select the "Hibernation" tab, and deselect the "Enable hibernation" checkbox. The file should disappear either right away or after the next reboot. If it doesn't, you should be able to safely delete it after disabling the option.

The protocol is important. IF you are running an IPX game, there are issues with IPX gaming in environments that have both XP/2000 machines and ME/98. This happened when we were playing Red Alert 2 using IPX. I'm not at home, so I'm going on memory of what options are on the screens. On the 2000/XP machines, the network configuration had more than one device showing up, even though we only had one NIC and one IPX configuration in the OS. The game had defaulted to the first. Changing both 2000/XP machines to the second device allowed the game to work. The 98/ME machines only had one device appearing in the list. I have no idea what causes the "phantom" device.

I can't speak regarding the other products, but Morpheus 1.3 and earlier do not work. Update your copy to 1.3.3, which was the latest last time I checked. This version works fine.

Quote: Remember that you cannot buy an upgrade from Win2kPro to WinXPHome. So unless you're buying the full edition (which would be much more expensive) you're going to have to go with WinXPPro. That is, unless he also owns a copy of 98 or ME that he might have been using before upgrading to 2000. The only limitation will be that he can't "upgrade" install the XP Home over 2000 Pro and will have to reformat the hard drive first and then provide the 98 or ME disk at the appropriate point in the installation to prove that he owns it. Quote: Noticing the A0 price difference between XP Pro & XP Home just makes me wonder how crippled is XP Home? It's a personal judgement call as to whether there is sufficient extra benefit in XP over 2000. To me, it is because of the added game compatibility and the fusion technology (i.e., no more DLL hell!!!!). We also have multiple users of the same computer in the house, and XP has simplified the login somewhat and added a "Switch User" feature so that someone else can log in without disturbing whatever I happen to have left running. Remote assistance is valuable to me, and I've insisted that all of the physically distant family members whose computers I sometimes support switch to XP so that when they have problems I can get in and deal with it. Funny thing is, I believe that a lot of the problems will go away simply from having switched from a 98 installation to an NT kernel. Next issue... Home vs. Pro... Again, a judgement call. The single most serious difference is the ability to log into an NT/2000 domain server with the Pro edition. At home, few of us do that. Then there is the encrypting features in NTFS that are only in Pro, which most of us don't need. The remote desktop is cool, but not often needed at home. Finally, there are a few tools that aren't in Home that are in Pro -- including the "Backup" utility. That was the only missing piece that I would have actually NEEDED to back my critical stuff up to my server, so I'm out looking for a workable freeware backup tool. I don't know whether I've missed any other major differences. Some will *NEED* the Professional edition even at home, and most of us will NOT. Take this for what value you can get out of it and do what will work best for you. Save the $$ if you can. I did.

I haven't had any luck getting this to install on Windows XP Pro, RC-2. Regardless of options, it says "Not enough disk space". I have two ideas: 1) It doesn't like something about XP's file system, and will need a work-around or a patch. 2) It has a bug in the installation that isn't allowing it to install to the user-selected path. Why I believe #2 might be the problem: 1) My XP machine has two partitions, a very small OS partition (drive C) with only about 500MB free, and a HUGE data partition (drive D) with about 25GB free. That second partition is the desired target. 2) When I couldn't get it to work, I went to the Windows 2000 machine, which only has one partition and has about 6GB free. 3) On that Windows 2000 machine, I changed the default path from "C:\Program Files\SSI\Pool of Radiance\" to "C:\Program Files\Pool of Radiance\" ... It *STILL* installed to the default path, totally ignoring my choice. So if it ignores the user-selected path and goes with the default all the time, then could it also be doing the same on my XP machine and trying to go to C: where I don't have enough space? I could test this by using Partition Magic to move another GB or so to C: and see what happens. Either way, it sucks that I can't get it to install to my XP machine to the drive that I want. I'll look forward to suggestions from anyone else who has purchased this game and has an idea of what is up with my situation. THANKS!!!!!

Follow-up: Since this has been confirmed to be a game bug rather than an XP compatibility issue, this message is no longer relevant to this section. However, in case anyone was following this, I'll bring closure to the issue. 1) I exported two registry branches in the HKEY_LOCAL_MACHINE/software section -- one for stormfront, and one for SSI 2) Moved the game and registry exports from the notebook computer to the desktop machine that had all of its free space on D: 3) Changed the registry key (stormfront piece) for "path" to reflect my actual D: path and the CD path to E: 4) Imported registry bits, and ran the poolii.exe ... in business. There are likely other work-arounds, but this was what worked for me.

Thanks for the information... This is the first fatal bug that I've ever encountered in the actual INSTALLTION routine for a game... I wonder how they'll be patching that, since the game hasn't actually installed yet. Guess I'll wait and see. Maybe I can move the registry and other bits from the notebook to the XP machine and change the path references in the process.

I have a Red Hat 7.1 server, with SAMBA upgraded to 2.2.1a. I have a script with an SMBMOUNT from RedHat to my older 2000 Pro installation's C$ and D$ shares (to read/write certain files on demand). Since installing (clean, reformatted) XP, I can't seem to get authorization for the C$ and D$ shares, using the exact same user ID and password configuration as before. The exact error as reported by SMBMOUNT is something like "Not Authorized" I have already gone through the Network Configuration Wizard, and then manually shared a few folders just to see whether THAT Worked, and it did indeed... I was able to SMBMOUNT and browse those, or SMBCLIENT and browse them. It just doesn't like those hidden administrative shares. I have no idea whether this is due to a change in the means of securing the C$ admin share, or something else that has broken the connectivity with SAMBA. I can already see that XP's security isn't identical to 2000. If anyone knows what I've missed regarding changes in XP's security model, please let me know. Thanks!!! Addendum... Connecting with XP to resources (directories and printers) shared by SAMBA does work. Addendum 2... I'm NOT running the "reset" crack. This copy is activated.

Sorry it took so long... I've been away. This worked BEAUTIFULLY. The only change is that in the local security policy, the #4 item to change has been renamed in RC-2 as: "Sharing and security model for local accounts", which should be changed to "Classic - Local users authenticate as themselves" EXCELLENT work in finding this. I have successfully mounted my administrative shares to my Linux server and deleted the dangerous "everyone" invisible shares.

How frustrating. I finally receive the RC-2 download notice, get home, start the download, and..... get 9-11k/s. This is far below the 1,300k/s that I have seen a time or two, the 200-400k/s that I get on a regular basis, and the 100k/s that I got while downloading RC-1. After 18MB, it freezes, never to download another single byte for the next hour or so. I was pretty sure that it's hosed at this point, so I kill it and restart. No resume capability exists. Fine, I'll just lose the time that I have just apparently lost in the first try, so I hit "start". User ID, password, GO..... Or not. "Invalid Login" error. Try over and over again. Same deal. Check the FAQ, and it says that this happens when I've exceeded my maximum number of download attempts. What a pain in the a$$. The solution? Go fill out a form, and it'll be processed in the order in which it was received. Grrrrrrrr..... I hope that .NET is going to be served on more robust equipment and/or sufficient bandwidth. I'd hate to be needing something on a deadline and find that their crap is overloaded.

It gets more interesting yet.... Playing with SMBCLIENT and observing the connection with Computer Management on XP, I can see that even when I log in from SAMBA with the same ID that has admin priveledge on the XP box, it still connects as a separate ID (since the server is the machine that is connecting) and also shows as "guest". If I remove the "everyone" share, and only add my actual ID to have sharing priveledges, then I can't get access from SAMBA even though I'm connecting with that same ID... So unlike 2000 and NT, which would both assume that if you use the same ID you're trying to log in under the same account, this one actually assumes that the same ID on a different box is NOT the same as the local. Now I can't figure how to force it to use the same. Interesting change of authentication. I have tried sending the ID as "xpboxname/username", and "xpboxname\\username" ... no luck. Tried forcing the netBIOS name to be the same as the XP box name, and still can't fool it. Damn it. The temporary solution, I suppose, is to add "\\sambaservername\username" to my XP box's user accounts. I hate that, as I still don't get the C$ and D$ admin shares. There HAS to be an answer. I can't quite figure whether this indicates that SAMBA needs to catch up, or a setting in XP.

It continues to be interesting. I created an invisible share (an entire drive, actually) by appending the "$" after the share (e.g., "reidyn$"), and successfully connected to that share with the expected rights on the Linux server. I also tried "escaping" the "$" in "C$" by substituting a "\$" for the "$".... no luck connecting to the administrative share. Also, for S&G, tried both uppercase and lowercase on the "C$" just in case it had become a case-sensitivity issue with Linux... no luck. I have noticed that in Windows XP, UNLIKE Windows 2000 and NT, explicitly sharing any resource causes a lengthy attribute change of some sort (which I haven't identified WHAT exactly), rather than just quickly creating the share as in earlier OSes. The higher the level being shared (i.e., the more files and folders beneath), the longer it takes. Don't know whether this has a connection... It would be interesting to try to connect to the Windows XP C$ share from a Windows 2000 or NT machine to see whether they can do it, or whether the fact that I can connect back to my own machine from the same machine is because XP is uniquely equipped for whatever changes have taken place. To p!ss me off even more, I can't even get a good search on Google or Deja... the "$" is dropped from the search criteria, and I can't figure a way to retain it.

No luck with the "IEEE 802.1" option... Disabled it, and still got the "Not Authorized" error... Damn.

Thank you both for your replies... Sorry so long for the delay in my own follow-up... my exams this week have preoccupied me. Clutch: ------- The exact "mount" that I'm using is as follows: mount -w -t smbfs -o username=ccjones,password=<<censored>>,dmask=0744,fmask=0744,workgroup=OLYMPUS //cthulu/d$ /data/cthulu-d Where the workstation that the server is trying to mount, obviously, is "cthulu", and the workgroup (no domain controller exists, only a workgroup designation) is "OLYMPUS". I get the error: 6792: tree connect failed: ERRDOS - ERRnoaccess (Access denied.) SMB connection failed However... if I explicitly share the d: volume on the workstation as "drive-d" and substitute "//cthulu/drive-d" for the "//cthulu/d$", it actually works. On the XP workstation, I can look in Computer Management console and see the existence of the d$ share, and even connect to it locally (as if going through the network) by typing "\\cthulu\d$" as the address in an explorer window. Bizarre. The explicit share will work, but I would prefer to use the hidden administrative share if at all possible (as I did with Win2000). If nothing else, it is cool being able to SSH into my server from work and obtain these details Four and Twenty: ---------------- I'm going to try changing that property as soon as I get home. Thanks for the suggestion!

IPX/SPX *should* die, but unfortunately it hasn't entirely died yet. Although *most* games DO have TCP/IP support, it seems that Westwood still prefers IPX for some reason. Red Alert 2, which is by no means an old or undesirable game, requires IPX to do multiplayer.

Are you running a software firewall on either machine? You should see that it isn't interfering. I have been using VNC between 2000 Server and 2000 Professional without any trouble.

For swapfiles, I think that the old 2.5x physical RAM rule is less relevant today than it was when we had very little physical RAM. The rule only made sense because you needed all you could possibly get, and 2.5x physical RAM was all that the system would use. Once you get enough physical RAM that you're not maxing out both it AND the swapfile, it no longer makes sense to make the swapfile as large as it can possibly get. The way to arrive at optimal size is to set it ridiculously large, run EVERYTHING that you could *POSSIBLY* do (WORST CASE) at one time (including image manipulation, for you Photoshop guys), see what the total committed memory is (using the task manager or a performance profiler), figure out how much is above and beyond physical RAM, add some reasonable safety margin (maybe 32 or 64 MB), and set the swapfile to that size. If you are still within a reasonable safety margin of physical RAM even after all of that, you can safely turn off the swapfile. The idea of a swapfile is to cover the physical RAM shortage that you might have. Once you get beyond a certain amount of physical RAM, swapfile is less important. To imagine that these guys with 512MB of RAM should need a 1.28GB swapfile is ludicrous.