Support for Windows 98/ME dropped

[peterz]

Starting from 2.8.5e, support for Windows 98/ME has been dropped.

When running it on 98/ME, users will be redirected to this thread, where they can vent their anger

[SpaceRat]

Well, I can understand that you don't feel like doing extra work to keep it Windows 98SE/ME compatible, but I see no reason in intentionally breaking it.

So far I have found nothing that makes it impossible to run Xchat on Windows 98SE. The only limitation is, that graphics (For emoticons or menus) can't be JPEG or PNG, but must be Windows .ICO format.

Please keep in mind that IRC is one of those things that older machines can do very well.

[Alchera]

So Microsoft drops all support for Windows 98SE/ME as gazetted and no one else is supposed to?

"The times, they are a changing."

[SpaceRat]

So Microsoft drops all support for Windows 98SE/ME as gazetted and no one else is supposed to?

"The times, they are a changing." :shock:

Microsoft doesn't provide updates to Windows 98SE/ME anymore, that's true.
But breaking apps for the sole purpose to break them is silly, especially if there is no benefit from doing so.
Not providing IE7, newer DirectX or latest MS Office Suites has a commercial benefit for Microsoft, when they successfully force people to buy a new Windows.
I don't see the benefit zed has, when people need to buy Windows XP or later.

While my software for online banking does not officially support Windows 98SE/ME in its latest version, this does just mean the softare
- discourages the use of Windows 98SE/ME
- doesn't guarantee their software will work in that environment.
But it doesn't include any limitation that would intentionally break it or keeps it from starting in Windows 9x.

As others have pointed out before, if the work-arounds in xchat are due to Unicode, it's as easy as linking against unicows.dll to make the apps work on Windows 95/98/98SE/ME again without any other special code:

http://www.microsoft.com.nsatc.net/globaldev/handson/dev/mslu_announce.mspx

And if the workarounds where just unicode related, providing own workarounds in the first place was the problem, a mistake in design.

The unicows.dll (MLSU) transparently provides the Unicode API that is missing from Windows 9x if the app is run on Windows 9x, but does nothing when the app runs on Windows NT 4 or higher.

A quick search for unicows.dll on my harddisk shows me, that the following apps rely on it:

- Abbyy FineReader
- Azureus (or its Installer or libs required)
- Azureus Vuze (or its Installer or libs required)
- eBay Turbolister
- CDex
- Cyberlink PowerDVD
- DirectConnect++
- Microsoft Drivers, like IntelliType/IntelliPoint
- StarOffice 7 (OpenOffice.org 2.0)
- StarOffice 8 (OpenOffice.org 2.1)
- The software for my cellular phone

For xchat this is especially a problem because a Windows 98SE PII-200 or so is fully sufficient for browsing the web, eMailing and IRCing.
I wouldn't see the reason why xchat requires Windows NT. xchat neither uses DirectX9, nor USB2.0 (Which even is available), nor IE7 (Which is only available on XP and higher)....

The latest version is mIRC v6.31 for Windows 95/98/ME/NT/2k/XP/Vista

KVirc also says nothing about requiring a specific version Windows (And it is far more advanced, when it comes to the GUI).

I can see no reason what makes Xchat so special that it would really require Windows NT.
I'll happily test a unicows.dll-build of Xchat in my Windows 98SE machine inside Virtual PC, if zed would be so kind to compile one and tell me what his own fixes were that he removed.

[Alchera]

I don't use Windows and therefore have no interest in something that really is petty.

Unless the intent is to stay with the past and use nothing but Windows 98 or (shudder) ME, I cannot actually comprehend the fuss.

I think a leaner, cleaner, XChat is what users want.

As for mIRC, so what? XChat has different stripes.

[SpaceRat]

I don't use Windows

Then why do you care?
You probably don't even understand the point.

Unless the intent is to stay with the past and use nothing but Windows 98 or (shudder) ME, I cannot actually comprehend the fuss. :roll:

Yeah, you don't understand.
I wouldn't want to use Windows 98SE for my work. But as long as a program works on it, it should be allowed to work on it.

I think a leaner, cleaner, XChat is what users want.

The best way would be to drop the whole code for opening an URL in the current browser for all those variants of Linux and use ShellExecute instead. Linux momos wouldn't be able to open URLs then anymore, until the different GUIs on top of that 32Bit-DOS get a decent and common API, but the code would be lean.

I bet there is more code
"on KDE do this, on Gnome do that, on Ubuntu Gnome do this and that, on Kubunto do another thing"
in Xchat than there is
"on Windows 9x do this, on Windows NT do that", let alone any place where it would say "on Windows 9x do this, on Windows NT4 do that, on Windows 2000 do that, on Windows XP do another thing, on Windows 2003 do blah, on Windows Vista do yet another thing".

You as a Linux-momo might not know: Windows has a common API. You write code for the Windows 32Bit API. Nor for a specific version of Windows.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Appdata
e.g. always points to the proper folder for storing application data.

Wether the Windows used has multi-user support at all (note the "CURRENT USER" in that path), wether it's "%WINDIR%\Application Data" (Windows 9x), "%WINDIR%\Profiles\<user name>\Application Data" (Windows NT4), "%SYSTEMDRIVE%\Documents and Settings\<user name>\Application Data" (Windows 2k and XP) or some other fancy shit (Windows Vista).

In Windows, you get what you want if you just use the API. Wether the file open dialog will show previews, details or whatever might differ between the Windows versions but not that you get a file open dialog with the API GetOpenFileName.

The only real thing that would prevent Xchat from running on older versions would be if it would require anything that was added later. Like DirectX9 or IE7.
I can't see anything this advanced inside Xchat.

The problem zed believes he had is, that Windows 98SE doesn't have GetOpenFileNameW (unicode) to stick with the example, but just GetOpenFileNameA (ANSI).
But by simply linking Xchat against unicows.dll he would just get GetOpenFileNameW. No other code changes required.
unicows.dll would even only be used on Windows 9x. On unicode-enabled versions, it would simply pass the call to the OS function.
It can't get any leaner.

All I ask for is to remove the nag that prevents Xchat from starting on a certain version of Windows and link the Windows version against that fucking unicows DLL that implements the "workarounds" zed wrote on his own before and removed now.
If he feels like he has to warn the users, he could add a different nag warning that no testing is done on Windows 98SE anymore and use of Xchat happens on the user's own risk (With "[X] Don't show this warning again" option).

PS: There is one feature I can imagine at the moment, that would prevent Xchat from working on Windows 9x or Windows NT:
True transparency instead of the broken gtk-- pseudo-transparency. Windows offers transparency since Windows 2000. The gtk-- transparency used in Xchat is broken like hell (The background behind the userlist doesn't get updated in queries, where there is no userlist + the notify list and other tool pages are copied as transparency into all other tabs when switching between them) and I wait for the fix since ages. Removing dependencies on gtk-- more and more would be a real step forward.
That would truely give better and leaner code (Which of course wouldn't work on inferior OSes anymore).
Windows is far better than the Linux geeks claim. Just not if you think within the limits you set yourself by "thinking Linux".

But even in this case, there would be no need to keep Xchat from starting. Just disable (gray out) the option for transparency on OSes that don't support it.
(And as the gtk-- code would probably still stay for the Linux version, one could as well still fall back to the inferior gtk-- routines if the OS doesn't have transparency)

[jlh]

So this means that version 2.8.5d will still work fine on those old old old old windows versions? If you use a very very very old old old version of windows, then what's the problem with using a chat program that is only a little bit old?

I'm not on windows, but I bet xchat 2.8.5d is a very good and very usable program. Use it. You're lacking much more features and security fixes by using an old windows than by using an old xchat.

[Huxlay]

So this means that version 2.8.5d will still work fine on those old old old old windows versions? If you use a very very very old old old version of windows, then what's the problem with using a chat program that is only a little bit old?

I'm not on windows, but I bet xchat 2.8.5d is a very good and very usable program. Use it. You're lacking much more features and security fixes by using an old windows than by using an old xchat.

I m also using this version but here working fine and properly.

[dorian]

Who is now using win98 It works perfect on win7.
[size=0]лазерная коррекция зрения[/size]