Alchera wrote:I don't use Windows
Then why do you care?
You probably don't even understand the point.
Alchera wrote: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.
Alchera wrote: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.
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.
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)