www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Do we need Win95/98/Me support?

reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
In this thread I would like a reason of trying to support Win95/98/Me to 
be discussed. I would like to see arguments for and against and, when 
there will be enough arguments, to vote, make a decision, and add 
supported Windows OS-es list to the docs, because now D is stamping 
itself by having undefined behaviour on Windows: one just can't tell, 
what will program in D do on certain version of Windows: crash/partially 
works/works?

My reasons against trying to support Win95/98/Me in D2:
* In Russia we have lots of outdated PC-s, and according to statistics 
of visitors of one site with educational thematics Win95+Win98+Me / All 
Windows visitors is 3+5+2 = 10 / 9_925 ~ 0.1%.
* If trying to support Win95/98/Me will be discarded, we can remove:
     1. `std.__fileinit`
     2. lots of small code duplicates like `useWfuncs ? WinFuncW() : 
WinFuncA()`
     3. some more complicated stuff like `SelUni` template in 
`std.windows.registry` or Windows `getcwd` implementation in `std.file`
* Developers will not be forced to create things that was enumerated in 
previous paragraph and fill themselves doing ungrateful work, because:
     1. Even command line arguments has never been implemented for 
Win95/98/Me in druntime (at least according to Git history of 
`rt.dmain2`, Issue 5926)
     2. For more than 8 months even Windows 2000 isn't supported at all 
(every D2 program crashes since 2.053, Issue 6024).
* This rejection isn't a breaking change because Win95/98/Me has never 
been supported by D2 (see previous paragraph).
* This rejection will allow to just add supported Windows OS-es list to 
the docs by claiming Win95/98/Me as unsupported.
Jan 22 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 22-01-2012 20:55, Denis Shelomovskij wrote:
 In this thread I would like a reason of trying to support Win95/98/Me to
 be discussed. I would like to see arguments for and against and, when
 there will be enough arguments, to vote, make a decision, and add
 supported Windows OS-es list to the docs, because now D is stamping
 itself by having undefined behaviour on Windows: one just can't tell,
 what will program in D do on certain version of Windows: crash/partially
 works/works?

 My reasons against trying to support Win95/98/Me in D2:
 * In Russia we have lots of outdated PC-s, and according to statistics
 of visitors of one site with educational thematics Win95+Win98+Me / All
 Windows visitors is 3+5+2 = 10 / 9_925 ~ 0.1%.
 * If trying to support Win95/98/Me will be discarded, we can remove:
 1. `std.__fileinit`
 2. lots of small code duplicates like `useWfuncs ? WinFuncW() : WinFuncA()`
 3. some more complicated stuff like `SelUni` template in
 `std.windows.registry` or Windows `getcwd` implementation in `std.file`
 * Developers will not be forced to create things that was enumerated in
 previous paragraph and fill themselves doing ungrateful work, because:
 1. Even command line arguments has never been implemented for
 Win95/98/Me in druntime (at least according to Git history of
 `rt.dmain2`, Issue 5926)
 2. For more than 8 months even Windows 2000 isn't supported at all
 (every D2 program crashes since 2.053, Issue 6024).
 * This rejection isn't a breaking change because Win95/98/Me has never
 been supported by D2 (see previous paragraph).
 * This rejection will allow to just add supported Windows OS-es list to
 the docs by claiming Win95/98/Me as unsupported.

I see absolutely no reason to support an OS that Microsoft does not support anymore, especially when it has such a negligible amount of users... -- - Alex
Jan 22 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Alex Rnne Petersen" <xtzgzorex gmail.com> wrote in message 
news:jfhppl$121g$1 digitalmars.com...
 I see absolutely no reason to support an OS that Microsoft does not 
 support anymore,

I don't think that's a good reason, since XP is still extremely relevent despite MS having pulled support. However...
 especially when it has such a negligible amount of users...

There's the good reason, along with the fact that 9x are really just such bad OSes anyway and would be a royal PITA to support. *This* is why I don't think we should bother to support 9x.
Jan 22 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2012 12:57 PM, Nick Sabalausky wrote:
 "Alex Rnne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jfhppl$121g$1 digitalmars.com...
 I see absolutely no reason to support an OS that Microsoft does not
 support anymore,

I don't think that's a good reason, since XP is still extremely relevent despite MS having pulled support. However...

MS still officially supports XP. Just a couple days ago, I got an automated update on it from them. I think MS's latest schedule is to officially abandon it in 2014. I think we ought to support things as long as MS officially does. After that, I'm game at abandoning official support, if for no other reason than not being able to develop/debug/test on those platforms.
Jan 22 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jfhtgm$195l$1 digitalmars.com...
 On 1/22/2012 12:57 PM, Nick Sabalausky wrote:
 "Alex Rnne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jfhppl$121g$1 digitalmars.com...
 I see absolutely no reason to support an OS that Microsoft does not
 support anymore,

I don't think that's a good reason, since XP is still extremely relevent despite MS having pulled support. However...

MS still officially supports XP. Just a couple days ago, I got an automated update on it from them. I think MS's latest schedule is to officially abandon it in 2014. I think we ought to support things as long as MS officially does. After that, I'm game at abandoning official support,

I *really* don't think we should be going purely by that. We still need to take into account actual users in the wild.
 if for no other reason than not being able to develop/debug/test on those 
 platforms.

That makes no sense at all. *Of course* it's perfectly possible to develop/debug/test on those platforms. Hell, I obtained a copy of 98 and installed it into a VM just last year. I could easily test/etc on that if I wanted to. *THIS* is what's important: 9x has been abandoned by users.
Jan 22 2012
prev sibling next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 22/01/2012 23:48, Jonathan M Davis wrote:
<snip>
 It would be insane to not support XP at this point. Not only does XP still
 support it, but there are tons of people who have refused to move on. IIRC,
 Microsoft was effectively forced to support it longer because of the number of
 people (particularly companies) who refused to upgrade. However, I see no
 reason to support anything older than XP.

Principle of least surprise. Somebody compiling for a given target platform should expect whether it runs on a given version of the platform to be down to the APIs the program uses, not the language the program is written in. Moreover, it seems a lot of currently maintained software still claims to support Win2000 - Firefox and OpenOffice for instance. For a whole programming language, the majority of whose users will be writing much simpler programs than this, to have higher system requirements than this seems absurd. Stewart.
Jan 22 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Adam D. Ruppe" <destructionator gmail.com> wrote in message 
news:ikyrsnddezjxlhukvnzl dfeed.kimsufi.thecybershadow.net...
 On Monday, 23 January 2012 at 05:30:48 UTC, Nick Sabalausky wrote:
 1. *Allow* people to use the XP UI (and no, I don't mean Luna).

You can...

No you can't. Note I said "UI", not "window theme". Even the third-party "Classic Shell" only takes things part-way (apperently, that's as far as it's even *able* to take things).
Jan 22 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:wqjqzbckwmahpotnfeom dfeed.kimsufi.thecybershadow.net...
 On Monday, 23 January 2012 at 05:30:48 UTC, Nick Sabalausky wrote:
 can they? Talk about digging one's own grave. Heck, I wouldn't be 
 surprised if Vista and Win7 (and Win8) have not only caused people to 
 stick with XP, but also caused a lot of Win->Lin converts - I'm getting 
 closer and closer to that myself.

Well, bought new notebook recently and decided there's no difference between migrating to win7 and linux, tried ubuntu 11 and linux mint 12, got too bad user experience with them. Linux causes high CPU load in idle mode - critical for notebooks - and that's in comparison with win7 loaded with OEM crapware.

Those are "newbie" Linuxes that, by default, use GUIs[1] which are known to be insanely bloated. Try something more like XFCE or LXDE. (Of course, you'd likely have far worse first-time user experience with anything other than Ubuntu or Mint :/ ) But yea, I'll grant the ones you tried shouldn't be as bloated as they are, and you shouldn't have to resort to more minimalistic UIs. I don't know what it is with Linux: Ten years ago, we had XP/2k, GNOME2 and KDE3. There was all this blah, blah, blah about Linux being soooo much more efficient, runs on a damn 386 or whatever, unlike "M$ bloatware". And yet, on the same hardware (rather sensibly-spec'ed, too) XP/2k ran smooth as silk, and GNOME2/KDE3 were absolute dogs. It was absolutely *rediculous* how bad Nautilus was - it felt *just like* when I tried to run Win95 on 4MB RAM. Things in Linux-land aren't nearly as bad now, but MS still seems to have their "efficiency" hat on a little straighter than they do.
 If you want vdpau (dxva for linux), you'll need nvidia driver, but its 
 installation is poorly automated and I had to install it from nvidia site 
 without automatic dependency resolution. Also hit one bug with Empathy IM 
 software. So linux still seems not an option to me.

Yea, stuff that isn't 100%-OSS can be a PITA with Ubuntu :( But I guess it's pretty bad though if that's a problem in Mint, too. [1] I don't even know what the fuck to call any of them anymore. "Window manager", "Desktop Environment", "Shell", "Compositor", and if I'm not mistaken there's even some damn hybrids or some such, and some can be used together, some can't, bleh. They're all the same damn things as far as I can tell :/
Jan 23 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Kagamin" <spam here.lot> wrote in message 
news:frjurfeotljhdadmbkmu dfeed.kimsufi.thecybershadow.net...
 On Monday, 23 January 2012 at 11:15:02 UTC, Nick Sabalausky wrote:
 Those are "newbie" Linuxes that, by default, use GUIs[1] which are known 
 to be insanely bloated.

Huh? More bloated than Aero?

I admit I haven't done any direct comparing on equivalent hardware. But my understanding (from Win7 users who said I should upgrade from XP) is that Win7 is supposedly at least as fast on the same hardware as XP. 'Course if they were just full of shit, which they could have been for all I know, then that would of course make me wrong. ;) Although, personally, if I were to get Win7, I wouldn't be touching Aero anyway. Yea, it's nicer than Luna, but that ain't saying much.
 Yea, stuff that isn't 100%-OSS can be a PITA with Ubuntu :(  But I guess 
 it's pretty bad though if that's a problem in Mint, too.

Well, I doubt the driver installation procedure is different in Mint. From what I understood from readme, one should somehow disable nouveau driver, change runlevel, reboot in console mode, do proper configuration and... I didn't read further.

Yea, when I see mention of things like "runlevel", my reaction is just "Screw it, I don't care that much." And I even know what the runlevel is. Anything that involves messing with a bunch of config files (especially xorg.conf), bash-fu, etc, just to accomplish some basic task leaves a very bad taste in my mouth. And they'll *never* get me to configure or recompile my kernel. Fuck. That. Shit. Ain't goin' near it. Things are *FAR* better than they were ten years ago, though. And back *then* they were all claiming things had gotten super-easy. The Ubuntu/Mint of 2001 was Mandrake, and even that "beginner's" linux was a bloated half-broken turd with a notably suicidal X11 (granted, X11 still isn't great). The "fantastic new super-easy package managers" made DLL hell look like paradise. Using the major window/desktop managers meant having a file manager that reacted about a minute after you clicked, and using any alternatives like afterstep or blackbox (especially afterstep) meant days worth of screwing around just to set up the most basic shit. As a Windows user, I had time to actually have a damn life (Growing up, I always thought of myself as a nerd - but 2001's Linux made me feel like a normal human). So I ran away screaming back to Windows. Now, having previously vacationed in hell, I'm relatively happy with 2012's Linux ;)
Jan 23 2012
prev sibling next sibling parent "Nick Sabalausky" <a a.a> writes:
"Bernard Helyer" <b.helyer gmail.com> wrote in message 
news:evddvsmtlbhryriggpca dfeed.kimsufi.thecybershadow.net...
 On Monday, 23 January 2012 at 11:15:02 UTC, Nick Sabalausky wrote:
 [1] I don't even know what the fuck to call any of them anymore. "Window 
 manager", "Desktop Environment", "Shell", "Compositor", and if I'm not 
 mistaken there's even some damn hybrids or some such, and some can be 
 used together, some can't, bleh.

A window manager handles window bar controls, positions of new windows, and the like. A shell is merely a term for something that allows input to the OS. A compositor takes the pixels pushed by other parts of the stack and applies GL magic to them. A Desktop Environment takes several of the above and packs them together in a single environment to create something (hopefully) cohesive.
They're all the same damn things as far as I can
 tell :/

That's because you don't know what you're talking about. :P

When it comes to that stuff, I really don't!
Jan 23 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Kiith-Sa" <42 theanswer.com> wrote in message 
news:dmyzlmuizdyseypvhxrn dfeed.kimsufi.thecybershadow.net...
 That said, it is true that some Linux vendors have gone crazy
 trying to "reinvent the GUI". Gnome3 and Unity (Ubuntu) are both 
 tabletized
 (Win8 is also going in similar direction) and both much more inefficient 
 than Gnome2 was.

Gnome3 and Unity are the main reasons I've been moving from Ubuntu to straight Debian.
 That said, KDE, which used to be bloated, has been optimizing quite 
 singificantly over the last few releases, and seem to plan to continue 
 doing it.
 KDE however always comes with some useless "Social desktop" features 
 enabled
 by default, which kill the performance (and make people think KDE is still 
 bloated - great PR, KDE!). Anyway, once that is disabled, at least on my 
 notebook Ubuntu/KDE is faster than Win7.

My main Linux machine is still Kubuntu 10.04 (yea, just haven't gotten around to upgrading). At the time, the word about KDE4 was that it had pretty much gotten over it's botched early releases. And yet I had some sort of major issue with it (don't remember what) that required upgrading to whatever brand new point release had just come out, umm, 4.5 or 4.6 (and even the upgrade process wasn't entirely straightforward, IIRC). So there KDE4 was, over it's initial problems, and upgraded to roughy the second or third "Really, it's good now!" release...and it's still the outright buggiest POS window/desktop manager I've ever used in my life. For example, the files on the desktop: Sometimes when I boot up, they're there. Usually, they're not. And when I boot, it'll decide on it's own which way it wants to be without me ever touching any settings whatsoever. And then dolphin's left-side tree-pane has a schizophrenic mind of it's own, too - although that one I have a feeling may actually be by design. 'Course, even *that* was some time ago now, and perhaps it's even better now, but...Even if it's perfect now, the only KDE I'll be willing to try anymore is Trinity. Although: How do you disable that "social desktop" stuff? This is the first I remember hearing about it, so I'm not sure I have it disabled or not.
Jan 23 2012
parent "Nick Sabalausky" <a a.a> writes:
"Kiith-Sa" <42 theanswer.com> wrote in message 
news:stutnobwbglkcuyeqzzr dfeed.kimsufi.thecybershadow.net...
 Disable akonadi: alt+f2, start typing akonadi, akonadi configuration menu 
 will appear, click it, go to akonadi server configuration tab, press stop 
 at the bottom right. Also uncheck Use internal MYsQL server. Notification 
 will show that akonadi has been stopped.

 Disable Semantic Desktop:
 1)System Settings -> Desktop Search -> Basic Settings, untick Nepomuk and 
 Strigi

 2)System Settings -> Desktop Search -> Desktop Query, untick "Index files 
 on removable media" and untick every folder under "Customise index 
 folders."
 3)System Settings -> Desktop Search -> Backup, set "Backup frequency" to 
 Disable

 Disable Notifications:
 a: System Settings -> Application and System Notifications -> Manage 
 Notifications, untick all the "Show me a message in a popup" under 
 "Desktop Search" and Semantic Desktop"

Ahh, thanks. Strigi was already off, and I couldn't find "Desktop Search -> Desktop Query" or "Desktop Search -> Backup", but everything else was on and I turned them off. We'll see how it goes.
 Note that KDE on Ubuntu has historically been fucked up.
 I've had much better experience on OpenSuse.
 (not sure why, but a lot of KDE people hate Kubuntu for
 giving KDE bad credit)

Interesting, I didn't know.
 I'm currently using Kubuntu 11.10 with KDE 4.7 though, and haven't
 encountered any bugs - except social desktop, which I disabled
 (Kubuntu/KDE4.6 wasn't usable - OpenSuse was)

 That said, KDE 4.8 is going to be released in 2 days, and it's mostly
 bugfixes and optimizations. So if you try KDE4 again, I recommend waiting
 for the next round of distros with 4.8 .

 KDE plans for 4.9 is also bugfixes, while 5.0 (don't panic) should be a 
 refactor
 without breaking user interface - but they plan to clean up the APIs (as 
 opposed to 4.0 - where they rewrote everything from scratch).

Yea, bugs aside, I actually don't really like the UI much anyway. For example, the notification system is not really great and is overused anyway (Example: Extract an archive in dolphin, the new directory for it appears, "Oh, ok, great, that was fast", go about your own business, a minute later see a message saying that only *NOW* has it actually finished extracting.)
 I'm not sure if Trinity has enough devs to do anything but maintain KDE3 
 comptatibility - MATE seems more promising to me (I liked Gnome 2 even 
 though
 I'm converted to KDE now).

Haven't heard of MATE, I'll look into it.
Jan 23 2012
prev sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 23/01/2012 00:23, Jonathan M Davis wrote:
<snip>
 Except that druntime and Phobos use those APIs. So, it matters. And since the
 number of people using pre-Win2K is extremely low, I see that as a complete
 non-issue.

In the cases where this is unavoidable, it can be dealt with by documenting which bits of druntime and Phobos require WinXP+ so that programmers wishing to support Win2k or below can avoid using them. <snip>
 The next version of Windows beyond that that it would be useful to be able to
 say that we don't support anything older than is Vista. I would _love_ to be
 able to do that Vista is the oldest that we support, because Vista added a
 bunch of useful API calls and the like. But we obviously can't do that anytime
 soon. The user base for XP is huge. The same can't be said of pre-Win2K.

Indeed, I'm inclined to think WinXP is still the most used OS now. Stewart.
Jan 23 2012
parent reply Todd VanderVeen <tdv part.net> writes:
Microsoft ended mainstream (i.e. free) support for XP nearly 3 years ago.

http://support.microsoft.com/lifecycle/?ln=en-gb&c2=1173

I would not make supporting an OS no longer supported by its vendor a priority,
particularly in light of the considerable efforts still needed elsewhere.
Jan 23 2012
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Todd VanderVeen" <tdv part.net> wrote in message 
news:jfkmod$gst$1 digitalmars.com...
 I would not make supporting an OS no longer supported by its vendor a 
 priority,

I still don't see how that's even relevent.
Jan 23 2012
prev sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, January 23, 2012 18:13:11 Nick Sabalausky wrote:
 "Todd VanderVeen" <tdv part.net> wrote in message
 news:jfkmod$gst$1 digitalmars.com...
 
 I would not make supporting an OS no longer supported by its vendor a
 priority,

I still don't see how that's even relevent.

Presumably, if the OS is no longer supported, then it's no longer used by enough people for it to be worth our time and effort to support. But that presupposes that the number of users is related to the level of support by the OS vendor, which in the case of XP, probably isn't really true. It may be by the time that Microsoft's support for XP is completely gone though. Ultimately, the question is user base. How many D programmers program for pre- XP Windows? I would expect the number to be very few. And given that D didn't really exist at that point, it's not like there are legacy programs that would need to be supported either. It would pretty much purely be D programmers writing new code for old systems which might be affected by the lack of Win9x support. At this point though, the key thing is being able to stop worrying about whether the W functions are supported. If we can assume at least Win2K, then the W functions are supported, and beyond that, the version of Windows doesn't really matter. None of the API calls that we're using at this point even need XP instead of Win2K. Beyond that, the question would be whether we could assume Vista and use its new API calls (XP didn't really add many calls), and the answer to that right now is obviously no. - Jonathan M Davis
Jan 23 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2012 7:47 PM, Jonathan M Davis wrote:
 Being able to remove all of the stuff like `useWfuncs` would definitely allow
us to
 clean up the Windows-related code in Phobos. Having to worry about it has
 definitely increased the complexity of the Windows API code in Phobos.

I wrote much of that code, and it did not make the code terribly dirty or gross or excessively complex. It's a minor detail. The main issue, as far as I'm concerned, is the existing code never gets tested on Win95 anymore, so we don't know if it works.
Jan 22 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2012 8:04 PM, Jonathan M Davis wrote:
 It's not horrible, but it does complicate the code. I know that it's caused
 some issues for the folks adding to std.windows.registry. And it has to be
 maintained as other changes are made. For instance, I'd like to go in and make
 std.file support string types of wchar and dchar. But toMBSz doesn't support
 anything other than strings of char, so I'm going to have to go and make
 toMBSz support other string types, and all for platforms that are more or less
 dead. If we got rid of useWfuncs, then that's not a problem anymore, but we
 can't do that as long as we try and support pre-Win2K.

Why make std.file support wchar and dchar? You triple the number of functions, all for rarely used cases, and one where the user can trivially convert wstring to string at the call site.
Jan 22 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2012 9:06 PM, Jonathan M Davis wrote:
 On Sunday, January 22, 2012 20:58:33 Walter Bright wrote:
 Why make std.file support wchar and dchar? You triple the number of
 functions, all for rarely used cases, and one where the user can trivially
 convert wstring to string at the call site.

It doesn't triple the number of functions. You just templatize them. You only get triple the number of functions if you actually use them with all 3 string types. But we've had complaints in general about Phobos functions only supporting string rather than char[] or wstring or whatever. Templatizing std.file's functions on string types helps alleviate that. And on Windows, it would even allow you to pass a wstring without having to convert to a string first and then back to a wstring to pass to the Windows API functions, which could reduce that number of string operations required for file operations. Regardless, the idea is to make the functions more flexible. They don't _need_ to be restricted to string specifically.

Templatizing is not the answer. The operating system file APIs take only wchar[] (Windows) and char[] (every one else). That means that two of the three will be nothing more than wrappers, anyway. Doing it as templates that means that any user of std.file has to read in the entire implementation of it, and everything std.file imports, rather than simply: void[] read(string filename); And yet nothing is accomplished, because two of the three will *necessarily* be wrappers. It's not an efficiency consideration because the conversion cost is meaningless next to the cost of opening a file. This triples the number of functions in practice, and becomes what I dread - a library that is miles wide and an inch deep. We need *depth*, not trivia. These one line wrappers are *trivia* because they take longer to look up the documentation for than simply converting the string yourself as necessary. Trivia does not belong in Phobos. Another way of looking at it is Phobos should provide snap-together building blocks, not trivial combinations of them.
Jan 22 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/22/2012 11:08 PM, Jonathan M Davis wrote:
 That happens anyway, because Phobos doesn't use .di files.

Phobos should use much more .di files. This will become more and more of an issue over time, as Phobos grows in complexity. We shouldn't preclude .di files.
 Aside from the toMBSz issue, templatizing them costs essentially nothing on
 the implementation side and yet enables the programmer to pass in whatever
 string type they want.

Phobos1 had the secant and cosecant functions, which were dumped for Phobos2. You could make exactly the same argument for them. It is an insufficient rationale. Phobos functions should do non-trivial things. It should not become an aggregation of trivia.
 The only issue is that if you were using a .di file
 (which we're not, and won't, because it kills inlining and CTFE - though
 neither affects std.file much), you'd then have to have the implementation in
 the .di file whereas currently you don't.

I agree that inlining and CTFE is a complete non-issue for std.file. It is not the reason that std.file is not a .di file - the reason is that nobody bothered to do the work to make it one. It should be one.
 Now, I don't think that it's all that big a deal that you have to convert
 whatever string type you're using to string to pass to functions in std.file,
 but I pretty always use string anyway. Other folks have complained in the
 newsgroup about the fact that Phobos functions generally force them to use
 string specifically.

Nobody is forced to use string. Just do a trivial conversion on calling the function. I emphasize trivial. A phobos function is even provided to do that - to!(string)(arg). Note that std.regex is templatized on the string type. This is necessary because regex performance is critical. This rationale does not apply to std.file.
Jan 22 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jfj0ao$3q9$1 digitalmars.com...
 Another way of looking at it is Phobos should provide snap-together 
 building blocks, not trivial combinations of them.

So whenever there's trivia to be done, it should be cluttering up the *user's* code instead? "Phobos: Batteries not included"
Jan 23 2012
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/23/2012 1:14 AM, Nick Sabalausky wrote:
 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:jfj0ao$3q9$1 digitalmars.com...
 Another way of looking at it is Phobos should provide snap-together
 building blocks, not trivial combinations of them.

So whenever there's trivia to be done, it should be cluttering up the *user's* code instead?

It's a very successful strategy used in Unix, which does not have a tool for everything, but one can easily construct a tool for everything by stringing together components with |
Jan 23 2012
parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound2 digitalmars.com> wrote in message 
news:jfjclq$slu$1 digitalmars.com...
 On 1/23/2012 1:14 AM, Nick Sabalausky wrote:
 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:jfj0ao$3q9$1 digitalmars.com...
 Another way of looking at it is Phobos should provide snap-together
 building blocks, not trivial combinations of them.

So whenever there's trivia to be done, it should be cluttering up the *user's* code instead?

It's a very successful strategy used in Unix, which does not have a tool for everything, but one can easily construct a tool for everything by stringing together components with |

It works in Unix because the building blocks are (mostly) well-designed and cover all needed use-cases. I think you'd have a hard time finding a Unix parallel to "Scatter to!blah(blah) all over your code in every single call to every fucking standard function that involves a string whenever you want your code to deal with wstring or dstring instead, or invent your own PhobosPlus on top of Phobos to paper up all the existing use-case holes." If you did, I'd probably consider it a blemish where a Unix component screwed up with modularity.
Jan 23 2012
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/23/12 3:14 AM, Nick Sabalausky wrote:
 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:jfj0ao$3q9$1 digitalmars.com...
 Another way of looking at it is Phobos should provide snap-together
 building blocks, not trivial combinations of them.

So whenever there's trivia to be done, it should be cluttering up the *user's* code instead?

In this case I think it's reasonable to have the user write read(to!string(filename)). It's simple composition. Andrei
Jan 23 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrei Alexandrescu" <SeeWebsiteForEmail erdani.org> wrote in message 
news:jfk1r6$2a5j$1 digitalmars.com...
 On 1/23/12 3:14 AM, Nick Sabalausky wrote:
 "Walter Bright"<newshound2 digitalmars.com>  wrote in message
 news:jfj0ao$3q9$1 digitalmars.com...
 Another way of looking at it is Phobos should provide snap-together
 building blocks, not trivial combinations of them.

So whenever there's trivia to be done, it should be cluttering up the *user's* code instead?

In this case I think it's reasonable to have the user write read(to!string(filename)). It's simple composition.

The problem is it's unnecessary composition. But I guess I'm not getting anywhere here.
Jan 23 2012
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
24.01.2012 2:32, Nick Sabalausky :
 "Andrei Alexandrescu"<SeeWebsiteForEmail erdani.org>  wrote in message
 news:jfk1r6$2a5j$1 digitalmars.com...
 On 1/23/12 3:14 AM, Nick Sabalausky wrote:
 "Walter Bright"<newshound2 digitalmars.com>   wrote in message
 news:jfj0ao$3q9$1 digitalmars.com...
 Another way of looking at it is Phobos should provide snap-together
 building blocks, not trivial combinations of them.

So whenever there's trivia to be done, it should be cluttering up the *user's* code instead?

In this case I think it's reasonable to have the user write read(to!string(filename)). It's simple composition.

The problem is it's unnecessary composition. But I guess I'm not getting anywhere here.

We have a proverb in Russia: "I told him about Thomas (), and he told me about Erema ()!" So, Walter say that calling `read(to!string(filename))` is easy and trivial. Yes it is. Nick say that it's unnecessary composition. Yes it is, it can be done in library. So, what is the problem? Nick point is that this composition is a common case, like reading file content as a string (readText function) and shouldn't be done by hands every time. Maybe. But one developer (or a couple) opinion isn't enough to answer this question. A think a voting is necessary to solve the problem.
Jan 24 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 22-01-2012 21:57, Nick Sabalausky wrote:
 "Alex Rnne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jfhppl$121g$1 digitalmars.com...
 I see absolutely no reason to support an OS that Microsoft does not
 support anymore,

I don't think that's a good reason, since XP is still extremely relevent despite MS having pulled support. However...

Well, extended support for XP still lasts until 2014.
 especially when it has such a negligible amount of users...

There's the good reason, along with the fact that 9x are really just such bad OSes anyway and would be a royal PITA to support. *This* is why I don't think we should bother to support 9x.

Yes... the OS APIs from those times were nightmare-ish. And the code in druntime/phobos to support those OSes ain't exactly pretty... -- - Alex
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 13:02:12 Walter Bright wrote:
 On 1/22/2012 12:57 PM, Nick Sabalausky wrote:
 "Alex R=C3=B8nne Petersen"<xtzgzorex gmail.com>  wrote in message
 news:jfhppl$121g$1 digitalmars.com...
=20
 I see absolutely no reason to support an OS that Microsoft does no=



 support anymore,

I don't think that's a good reason, since XP is still extremely rel=


 despite MS having pulled support. However...

MS still officially supports XP. Just a couple days ago, I got an aut=

 update on it from them. I think MS's latest schedule is to officially=

 abandon it in 2014.
=20
 I think we ought to support things as long as MS officially does. Aft=

 that, I'm game at abandoning official support, if for no other reason=

 not being able to develop/debug/test on those platforms.

It would be insane to not support XP at this point. Not only does XP st= ill=20 support it, but there are tons of people who have refused to move on. I= IRC,=20 Microsoft was effectively forced to support it longer because of the nu= mber of=20 people (particularly companies) who refused to upgrade. However, I see = no=20 reason to support anything older than XP. Microsoft doesn't, and the nu= mber of=20 people using Win2K or older is going to be rather small. For the most p= art, I=20 think that if you support XP, you end up supporting 2K, since they're n= ot all=20 that different, so I don't know that it really hurts us to say that we = support=20 Win2K, but I'd love to be able to drop the extra stuff that we do to su= pport=20 pre-Win2K. - Jonathan M Davis
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 13:02:12 Walter Bright wrote:
 I think we ought to support things as long as MS officially does. After
 that, I'm game at abandoning official support, if for no other reason than
 not being able to develop/debug/test on those platforms.

Then can we just agree to drop support for pre-Win2K Windows platforms? Being able to remove all of the stuff like `useWfuncs` would definitely allow us to clean up the Windows-related code in Phobos. Having to worry about it has definitely increased the complexity of the Windows API code in Phobos. - Jonathan M Davis
Jan 22 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
I find it kind of funny that someone would use a *new* language to
support an *ancient* platform. If someone is still hacking with win9x
support I bet their dev environment is -- VC6.
Jan 22 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.722.1327291162.16222.digitalmars-d puremagic.com...
I find it kind of funny that someone would use a *new* language to
 support an *ancient* platform. If someone is still hacking with win9x
 support I bet their dev environment is -- VC6.

While I agree 9x isn't worth supporting, calling it "ancient" is pure hyperbole. CP/M is ancient. ProDOS is arguably ancient. Hell, Win2 could even be called ancient. Win9x is just simply old/outdated. Christ, it includes an OS (WinMe) that's arguably *ONE* version prior to a version that's still heavily used - XP. (Hell, even Win98 was the version that *most* people used immediately prior to the still-heavily-used XP). I know I'm going all off on something that really is nitpicky, but misuse of grandiose words like "ancient", "epic", etc., to refer to fairly trivial matters is a bit of a pet peeve... (Hell, using "ancient" to refer to "computers more than 5-10 years old" is itself rather..."ancient".)
Jan 22 2012
parent "Nick Sabalausky" <a a.a> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:jfis68$2uv7$1 digitalmars.com...
 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
 news:mailman.722.1327291162.16222.digitalmars-d puremagic.com...
I find it kind of funny that someone would use a *new* language to
 support an *ancient* platform. If someone is still hacking with win9x
 support I bet their dev environment is -- VC6.

While I agree 9x isn't worth supporting, calling it "ancient" is pure hyperbole. CP/M is ancient. ProDOS is arguably ancient. Hell, Win2 could even be called ancient. Win9x is just simply old/outdated. Christ, it includes an OS (WinMe) that's arguably *ONE* version prior to a version that's still heavily used - XP. (Hell, even Win98 was the version that *most* people used immediately prior to the still-heavily-used XP). I know I'm going all off on something that really is nitpicky, but misuse of grandiose words like "ancient", "epic", etc., to refer to fairly trivial matters is a bit of a pet peeve... (Hell, using "ancient" to refer to "computers more than 5-10 years old" is itself rather..."ancient".)

FWIW, I do agree that "new language on an...outdated...platform" does have an air of anachronism.
Jan 22 2012
prev sibling next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
22.01.2012 23:55, Denis Shelomovskij пишет:
 In this thread I would like a reason of trying to support Win95/98/Me to
 be discussed.

In the case Win95/98/Me will be marked as unsupported, I will volunteer to remove unnecessary code from druntime/Phobos.
Jan 22 2012
prev sibling next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 23, 2012 00:14:27 Stewart Gordon wrote:
 On 22/01/2012 23:48, Jonathan M Davis wrote:
 <snip>
 
 It would be insane to not support XP at this point. Not only does XP
 still support it, but there are tons of people who have refused to move
 on. IIRC, Microsoft was effectively forced to support it longer because
 of the number of people (particularly companies) who refused to
 upgrade. However, I see no reason to support anything older than XP.

<snip> Principle of least surprise. Somebody compiling for a given target platform should expect whether it runs on a given version of the platform to be down to the APIs the program uses, not the language the program is written in.

Except that druntime and Phobos use those APIs. So, it matters. And since the number of people using pre-Win2K is extremely low, I see that as a complete non-issue.
 Moreover, it seems a lot of currently maintained software still claims to
 support Win2000 - Firefox and OpenOffice for instance.  For a whole
 programming language, the majority of whose users will be writing much
 simpler programs than this, to have higher system requirements than this
 seems absurd.

As I said in my previous post, while ideally we'd say that we don't support anything older than WinXP, saying that we support Win2K probably costs us nothing. It's the pre-Win2K that's the problem with the lack of W functions and the like. The next version of Windows beyond that that it would be useful to be able to say that we don't support anything older than is Vista. I would _love_ to be able to do that Vista is the oldest that we support, because Vista added a bunch of useful API calls and the like. But we obviously can't do that anytime soon. The user base for XP is huge. The same can't be said of pre-Win2K. So, I really think that we should say that we don't support pre-Win2K, and I'd like to say that we don't support pre-XP, but I don't think that it hurts us any to say that we support Win2K. - Jonathan M Davis
Jan 22 2012
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.716.1327278278.16222.digitalmars-d puremagic.com...
 On Monday, January 23, 2012 00:14:27 Stewart Gordon wrote:
 On 22/01/2012 23:48, Jonathan M Davis wrote:
 <snip>

 It would be insane to not support XP at this point. Not only does XP
 still support it, but there are tons of people who have refused to move
 on. IIRC, Microsoft was effectively forced to support it longer because
 of the number of people (particularly companies) who refused to
 upgrade. However, I see no reason to support anything older than XP.

<snip> Principle of least surprise. Somebody compiling for a given target platform should expect whether it runs on a given version of the platform to be down to the APIs the program uses, not the language the program is written in.

Except that druntime and Phobos use those APIs. So, it matters. And since the number of people using pre-Win2K is extremely low, I see that as a complete non-issue.
 Moreover, it seems a lot of currently maintained software still claims to
 support Win2000 - Firefox and OpenOffice for instance.  For a whole
 programming language, the majority of whose users will be writing much
 simpler programs than this, to have higher system requirements than this
 seems absurd.

As I said in my previous post, while ideally we'd say that we don't support anything older than WinXP, saying that we support Win2K probably costs us nothing. It's the pre-Win2K that's the problem with the lack of W functions and the like. The next version of Windows beyond that that it would be useful to be able to say that we don't support anything older than is Vista. I would _love_ to be able to do that Vista is the oldest that we support, because Vista added a bunch of useful API calls and the like. But we obviously can't do that anytime soon. The user base for XP is huge. The same can't be said of pre-Win2K. So, I really think that we should say that we don't support pre-Win2K, and I'd like to say that we don't support pre-XP, but I don't think that it hurts us any to say that we support Win2K.

I agree on all points. But you know, the really bizarre thing is, *all* MS has to do to win over all the XP people (or at least the majority of them) is two simple things: 1. *Allow* people to use the XP UI (and no, I don't mean Luna). It's that simple: Just *quit* making UI changes mandatory (a lesson Mozilla could stand to learn, too, especially since they allegedly care so much about configurability). 2. Ditch the AV-crippling and driver-revocation bullshit. That's it. That's all they have to do. The core of Win7 is basically solid (from what I hear). But they can't handle that, can they? Talk about digging one's own grave. Heck, I wouldn't be surprised if Vista and Win7 (and Win8) have not only caused people to stick with XP, but also caused a lot of Win->Lin converts - I'm getting closer and closer to that myself. All they (or Mozilla) seem to care about anymore is just fucking around with the UI everyone already liked - and redoing it over, and over, and over.
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 19:55:21 Walter Bright wrote:
 On 1/22/2012 7:47 PM, Jonathan M Davis wrote:
 Being able to remove all of the stuff like `useWfuncs` would definitely
 allow us to clean up the Windows-related code in Phobos. Having to
 worry about it has definitely increased the complexity of the Windows
 API code in Phobos.

gross or excessively complex. It's a minor detail. The main issue, as far as I'm concerned, is the existing code never gets tested on Win95 anymore, so we don't know if it works.

It's not horrible, but it does complicate the code. I know that it's caused some issues for the folks adding to std.windows.registry. And it has to be maintained as other changes are made. For instance, I'd like to go in and make std.file support string types of wchar and dchar. But toMBSz doesn't support anything other than strings of char, so I'm going to have to go and make toMBSz support other string types, and all for platforms that are more or less dead. If we got rid of useWfuncs, then that's not a problem anymore, but we can't do that as long as we try and support pre-Win2K. - Jonathan M Davis
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 20:58:33 Walter Bright wrote:
 Why make std.file support wchar and dchar? You triple the number of
 functions, all for rarely used cases, and one where the user can trivially
 convert wstring to string at the call site.

It doesn't triple the number of functions. You just templatize them. You only get triple the number of functions if you actually use them with all 3 string types. But we've had complaints in general about Phobos functions only supporting string rather than char[] or wstring or whatever. Templatizing std.file's functions on string types helps alleviate that. And on Windows, it would even allow you to pass a wstring without having to convert to a string first and then back to a wstring to pass to the Windows API functions, which could reduce that number of string operations required for file operations. Regardless, the idea is to make the functions more flexible. They don't _need_ to be restricted to string specifically. - Jonathan M Davis
Jan 22 2012
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Monday, 23 January 2012 at 05:30:48 UTC, Nick Sabalausky wrote:
 1. *Allow* people to use the XP UI (and no, I don't mean Luna).

You can...
 Heck, I wouldn't be surprised if Vista and Win7 (and Win8) have 
 not only caused people to stick with XP, but also caused a lot 
 of Win->Lin converts

I'd be very surprised if it did.
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, January 23, 2012 00:31:24 Nick Sabalausky wrote:
 But you know, the really bizarre thing is, *all* MS has to do to win over
 all the XP people (or at least the majority of them) is two simple things:

That may help, but it wouldn't be enough. There are companies which refused to go to XP service pack 3 (and maybe service pack 2 - I don't remember) because it broke software that they had (particularly software that had to do with keeping track of what employees did on their computers IIRC). If a service pack broke that, there's no way that they'd upgrade to Vista or 7. Also, there are tons of Windows users who see no reason to upgrade. Why bother? Especially when it costs money? If they get a new computer which has Windows 7 on it, fine, but they won't upgrade their existing systems. XP works fine. And when you consider the IT guys, they frequently want everyone on exactly the same OS, and they don't want to bother upgrading anyone, so they avoid upgrading for as long as possible. Heck, my Dad was ticked with XP for being more of a resource hog than Win2K and refused to upgrade to XP until he absolutely had to recently because of issues with Norton. He's certainly not going to mess with Vista or 7 with their fancy UIs until he absolutely has to. There's nothing that Vista or 7 offers that he considers worth the upgrade. There are plenty of reasons to not upgrade. I don't think that Microsoft _can_ really do anything to get everyone to upgrade short of refusing to support XP any longer, which would result in a ton of ticked off customers. Sure, they could do some stuff to make more people willing to upgrade, but in the long run, the only thing that's going to get people in general off of XP is the fact that they won't be able to get it for new computers, so when they get a new computer, they end up with whatever the newest version of Windows is. - Jonathan M Davis
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 22, 2012 22:56:23 Walter Bright wrote:
 Templatizing is not the answer. The operating system file APIs take only
 wchar[] (Windows) and char[] (every one else). That means that two of the
 three will be nothing more than wrappers, anyway.
 
 Doing it as templates that means that any user of std.file has to read in
 the entire implementation of it, and everything std.file imports, rather
 than simply:
 
     void[] read(string filename);

That happens anyway, because Phobos doesn't use .di files.
 And yet nothing is accomplished, because two of the three will *necessarily*
 be wrappers.

 It's not an efficiency consideration because the conversion cost is
 meaningless next to the cost of opening a file.
 
 This triples the number of functions in practice, and becomes what I dread -
 a library that is miles wide and an inch deep. We need *depth*, not trivia.
 These one line wrappers are *trivia* because they take longer to look up
 the documentation for than simply converting the string yourself as
 necessary. Trivia does not belong in Phobos.
 
 Another way of looking at it is Phobos should provide snap-together building
 blocks, not trivial combinations of them.

Aside from the toMBSz issue, templatizing them costs essentially nothing on the implementation side and yet enables the programmer to pass in whatever string type they want. The only issue is that if you were using a .di file (which we're not, and won't, because it kills inlining and CTFE - though neither affects std.file much), you'd then have to have the implementation in the .di file whereas currently you don't. So, as far as I can see, templatizing them costs us nothing (aside from the toMBSz issue) and makes the functions more flexible. Now, I don't think that it's all that big a deal that you have to convert whatever string type you're using to string to pass to functions in std.file, but I pretty always use string anyway. Other folks have complained in the newsgroup about the fact that Phobos functions generally force them to use string specifically. So, it seemed like a no-brainer to just templatize the std.file functions on string type. toUTFz makes it trivially possible everyone but on pre-Win2K systems which have to worry about their strings being ANSI instead of UTF-8. - Jonathan M Davis
Jan 22 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
Well, regardless of whether we want to templatize anything in std.file or turn 
it into a .di file or anything else we might want to do to, I think that 
useWfuncs and the corresponding support for Win9x should be dropped.

- Jonathan M Davis
Jan 23 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 23 January 2012 at 05:30:48 UTC, Nick Sabalausky wrote:
 can they? Talk about digging one's own grave. Heck, I wouldn't 
 be surprised if Vista and Win7 (and Win8) have not only caused 
 people to stick with XP, but also caused a lot of Win->Lin 
 converts - I'm getting closer and closer to that myself.

Well, bought new notebook recently and decided there's no difference between migrating to win7 and linux, tried ubuntu 11 and linux mint 12, got too bad user experience with them. Linux causes high CPU load in idle mode - critical for notebooks - and that's in comparison with win7 loaded with OEM crapware. If you want vdpau (dxva for linux), you'll need nvidia driver, but its installation is poorly automated and I had to install it from nvidia site without automatic dependency resolution. Also hit one bug with Empathy IM software. So linux still seems not an option to me.
Jan 23 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 23 January 2012 at 11:15:02 UTC, Nick Sabalausky wrote:
 Those are "newbie" Linuxes that, by default, use GUIs[1] which 
 are known to be insanely bloated.

Huh? More bloated than Aero?
 Yea, stuff that isn't 100%-OSS can be a PITA with Ubuntu :(  
 But I guess it's pretty bad though if that's a problem in Mint, 
 too.

Well, I doubt the driver installation procedure is different in Mint. From what I understood from readme, one should somehow disable nouveau driver, change runlevel, reboot in console mode, do proper configuration and... I didn't read further.
Jan 23 2012
prev sibling next sibling parent "Bernard Helyer" <b.helyer gmail.com> writes:
On Monday, 23 January 2012 at 11:15:02 UTC, Nick Sabalausky wrote:
 [1] I don't even know what the fuck to call any of them 
 anymore. "Window manager", "Desktop Environment", "Shell", 
 "Compositor", and if I'm not mistaken there's even some damn 
 hybrids or some such, and some can be used together, some 
 can't, bleh.

A window manager handles window bar controls, positions of new windows, and the like. A shell is merely a term for something that allows input to the OS. A compositor takes the pixels pushed by other parts of the stack and applies GL magic to them. A Desktop Environment takes several of the above and packs them together in a single environment to create something (hopefully) cohesive.
They're all the same damn things as far as I can
 tell :/

That's because you don't know what you're talking about. :P
Jan 23 2012
prev sibling next sibling parent "Kiith-Sa" <42 theanswer.com> writes:
On Monday, 23 January 2012 at 11:42:16 UTC, Kagamin wrote:
 On Monday, 23 January 2012 at 11:15:02 UTC, Nick Sabalausky 
 wrote:
 Those are "newbie" Linuxes that, by default, use GUIs[1] which 
 are known to be insanely bloated.

Huh? More bloated than Aero?
 Yea, stuff that isn't 100%-OSS can be a PITA with Ubuntu :(  
 But I guess it's pretty bad though if that's a problem in 
 Mint, too.

Well, I doubt the driver installation procedure is different in Mint. From what I understood from readme, one should somehow disable nouveau driver, change runlevel, reboot in console mode, do proper configuration and... I didn't read further.

Actually, no. You click a "Additional Drivers" button, that will just pop up as a notification if you have an AMD or NVidia GPU. Then you click at the driver you want to install, and click "Activate". And maybe "Ok" or "Close" after that.That is the way it works both on Ubuntu and on Mint. It's not easy to miss. You don't install the driver from NVidia's site - you have the newest driver prepackaged already. In general, on Linux you don't install software by searching on the net, you use the package manager/software center GUI or do "apt-get install program". That said, it is true that some Linux vendors have gone crazy trying to "reinvent the GUI". Gnome3 and Unity (Ubuntu) are both tabletized (Win8 is also going in similar direction) and both much more inefficient than Gnome2 was. That said, KDE, which used to be bloated, has been optimizing quite singificantly over the last few releases, and seem to plan to continue doing it. KDE however always comes with some useless "Social desktop" features enabled by default, which kill the performance (and make people think KDE is still bloated - great PR, KDE!). Anyway, once that is disabled, at least on my notebook Ubuntu/KDE is faster than Win7. XFCE is even faster, and is getting full-featured - it doesn't have much visual flair, though, if you want that. LXDE is extremely lightweight, but doesn't have many features. Enlightenment started popping up recently, which is (very) fast _and_ looks awesome, but AFAIK written in optimized C and crashy. From my experience, OpenSUSE is now both stable and friendly to Windows power users. Ubuntu/Mint are more oriented towards complete newbies or people who only browse/use office suite.
Jan 23 2012
prev sibling next sibling parent "Kiith-Sa" <42 theanswer.com> writes:
Disable akonadi: alt+f2, start typing akonadi, akonadi 
configuration menu will appear, click it, go to akonadi server 
configuration tab, press stop at the bottom right. Also uncheck 
Use internal MYsQL server. Notification will show that akonadi 
has been stopped.

Disable Semantic Desktop:
1)System Settings -> Desktop Search -> Basic Settings, untick 
Nepomuk and Strigi

2)System Settings -> Desktop Search -> Desktop Query, untick 
“Index files on removable media” and untick every folder 
under “Customise index folders…”
3)System Settings -> Desktop Search -> Backup, set “Backup 
frequency” to Disable

Disable Notifications:
a: System Settings -> Application and System Notifications -> 
Manage Notifications, untick all the “Show me a message in a 
popup” under “Desktop Search” and Semantic Desktop”



Note that KDE on Ubuntu has historically been fucked up.
I've had much better experience on OpenSuse.
(not sure why, but a lot of KDE people hate Kubuntu for
giving KDE bad credit)

I'm currently using Kubuntu 11.10 with KDE 4.7 though, and haven't
encountered any bugs - except social desktop, which I disabled
(Kubuntu/KDE4.6 wasn't usable - OpenSuse was)

That said, KDE 4.8 is going to be released in 2 days, and it's 
mostly
bugfixes and optimizations. So if you try KDE4 again, I recommend 
waiting
for the next round of distros with 4.8 .

KDE plans for 4.9 is also bugfixes, while 5.0 (don't panic) 
should be a refactor
without breaking user interface - but they plan to clean up the 
APIs (as opposed to 4.0 - where they rewrote everything from 
scratch).


I'm not sure if Trinity has enough devs to do anything but 
maintain KDE3 comptatibility - MATE seems more promising to me (I 
liked Gnome 2 even though
I'm converted to KDE now).
Jan 23 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 23 January 2012 at 12:31:28 UTC, Kiith-Sa wrote:
 You click a "Additional Drivers" button, that will just pop up 
 as
 a notification if you have an AMD or NVidia GPU. Then you click 
 at
 the driver you want to install, and click "Activate". And maybe 
 "Ok"
 or "Close" after that.That is the way it works both on Ubuntu 
 and on Mint.

 It's not easy to miss.

Dunno, Driver manager (or something like that) showed me an empty list saying I don't have proprietary drivers installed. Don't know how to find prepackaged drivers. Missed it in both Mint and Ubuntu.
 You don't install the driver from NVidia's site - you have the 
 newest
 driver prepackaged already.

 In general, on Linux you don't install software by searching on 
 the net,
 you use the package manager/software center GUI or do "apt-get 
 install program".

Well, the complicated thing is that my notebook is new and it has latest hardware: support for GeForce GT 520MX was added to driver 285, but nvidia-current is 280. I don't know what this "support" means; if vdpau will work with prepackaged driver, that's great.
 That said, it is true that some Linux vendors have gone crazy
 trying to "reinvent the GUI". Gnome3 and Unity (Ubuntu) are 
 both tabletized
 (Win8 is also going in similar direction) and both much more 
 inefficient than Gnome2 was.

Wikipedia mentions that Ubuntu has an issue with high power consumption. I'm not sure whether it's my problem, but they try to address it in Ubuntu 12 using very nifty tricks like putting USB controllers to low power mode and hunting down software with frequent wakeups and filing bugs against them. They don't consider GUI system as a culprit at all.
 That said, KDE, which used to be bloated, has been optimizing 
 quite singificantly over the last few releases, and seem to 
 plan to continue doing it.
 KDE however always comes with some useless "Social desktop" 
 features enabled
 by default, which kill the performance (and make people think 
 KDE is still bloated - great PR, KDE!). Anyway, once that is 
 disabled, at least on my notebook Ubuntu/KDE is faster than 
 Win7.

 XFCE is even faster, and is getting full-featured - it doesn't 
 have much
 visual flair, though, if you want that.

I don't have performance issues, I have high CPU load in idle mode. I'm currently on win7 and the cooler seems to be off, in Ubuntu and Mint the cooler worked at high speed and quite warm air was coming from the radiator.
 From my experience, OpenSUSE is now both stable and friendly to
 Windows power users. Ubuntu/Mint are more oriented towards 
 complete newbies
 or people who only browse/use office suite.

The wubi option is quite amasing, I hesitate to go for full-fledged dual-boot installation.
Jan 23 2012
prev sibling next sibling parent "Kiith-Sa" <42 theanswer.com> writes:
 Dunno, Driver manager (or something like that) showed me an 
 empty list saying I don't have proprietary drivers installed. 
 Don't know how to find prepackaged drivers. Missed it in both 
 Mint and Ubuntu.

 Well, the complicated thing is that my notebook is new and it 
 has latest hardware: support for GeForce GT 520MX was added to 
 driver 285, but nvidia-current is 280. I don't know what this 
 "support" means; if vdpau will work with prepackaged driver, 
 that's great.

VDPAU doesn't work with the OSS drivers at the moment - you need the binary driver for that. It does sound like Ubuntu simply doesn't have the newest driver packaged yet - you can either wait for 12.04 - or - sudo apt-add-repository ppa:ubuntu-x-swat/x-updates sudo apt-get install nvidia-graphics-drivers should install unofficially packaged driver 290 found here: https://launchpad.net/~ubuntu-x-swat/+archive/x-updates?field.series_filter=natty (WARNING: didn't test it)
 Wikipedia mentions that Ubuntu has an issue with high power 
 consumption. I'm not sure whether it's my problem, but they try 
 to address it in Ubuntu 12 using very nifty tricks like putting 
 USB controllers to low power mode and hunting down software 
 with frequent wakeups and filing bugs against them. They don't 
 consider GUI system as a culprit at all.

The main power issue is the ASPM bug in the Linux kernel, fix for which should be backported to kernel in Ubuntu 12.04 (AFAIK). I do have about 7 hours battery (coding) on my notebook, which is more than people have on Win7 (university notebook - paid by the EU) - but that's KDE - with social desktop - and desktop effects - disabled.
 I don't have performance issues, I have high CPU load in idle 
 mode. I'm currently on win7 and the cooler seems to be off, in 
 Ubuntu and Mint the cooler worked at high speed and quite warm 
 air was coming from the radiator.

Weird. Doesn't happen to me on any distro. That said, did you look at the system monitor? Notice which process is using up the CPU - if it's something in Unity, then KDE/XFCE/LXDE/whatever can fix your problem. Unity IS a resource hog, but it shouldn't cause a permanent load on the CPU. There is a possible cause, but that would be GPU, not CPU load: NVidia stated that they don't intend to support Optimus on Linux. What's worse, if you have an Optimus GPU, it runs on 100% all the time even though you're not using it. That said, there are third party programs that provide Optimus support, Bumblebee and Ironhide. Both are alpha at the moment, though. Work on my notebook (which has Optimus) - but I don't use graphics too much, so I just used Ironhide to disable the NVidia GPU and only enable it when playing games, running emulators or modelling (Blender). That saves a LOT of battery life. 3 hr when GeForce is running constantly vs 7hr when it's not.
 The wubi option is quite amasing, I hesitate to go for 
 full-fledged dual-boot installation.

Wubi slows the system down quite drastically. (or at least did a few years ago, didn't test it recently)
Jan 23 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 23 January 2012 at 20:38:21 UTC, Kiith-Sa wrote:
 VDPAU doesn't work with the OSS drivers at the moment - you
 need the binary driver for that.

I was wrong. Seems like the driver installation was so transparent, I barely noticed anything, at least, bumblebee did it for me. Though there seems to be no way have vdpau on my hybrid graphics today.
 I don't have performance issues, I have high CPU load in idle 
 mode. I'm currently on win7 and the cooler seems to be off, in 
 Ubuntu and Mint the cooler worked at high speed and quite warm 
 air was coming from the radiator.

Weird. Doesn't happen to me on any distro. That said, did you look at the system monitor?

System monitor reports some weird information for me: it claims all processes are sleeping and consume 0% CPU yet on the processors tab it shows constant load of about 10% jumping from core to core. Anyway, I switched back to Mint and plan to address my issues on their forum.
 Notice which process is using up the CPU - if it's something in 
 Unity,
 then KDE/XFCE/LXDE/whatever can fix your problem. Unity IS a 
 resource hog, but it shouldn't cause a permanent load on the
 CPU.

 There is a possible cause, but that would be GPU, not CPU load:
 NVidia stated that they don't intend to support Optimus on 
 Linux.
 What's worse, if you have an Optimus GPU, it runs on 100% all 
 the time even though you're not using it.

It shouldn't produce heat because there's no load on it. Bumblebee 3 claims to turn off discrete GPU by default an turn it on only on demand when an application is run with optirun.
Jan 24 2012
prev sibling next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
22.01.2012 23:55, Denis Shelomovskij пишет:
 In this thread I would like a reason of trying to support Win95/98/Me to
 be discussed.

"Get rid of win9x support" pull requests: https://github.com/D-Programming-Language/druntime/pull/140 https://github.com/D-Programming-Language/phobos/pull/406 Diff without indention: https://github.com/D-Programming-Language/phobos/pull/406/files?w=1 Phobos will reduce in weight about 500 lines.
Jan 24 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
We need a decision on this topic.

Actively maintaining support for new features?

Cleaning out Win9x code?
Jan 26 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, January 26, 2012 19:21:53 Martin Nowak wrote:
 We need a decision on this topic.
 
 Actively maintaining support for new features?
 
 Cleaning out Win9x code?

There doesn't seem to be much support for continuing support of Win9x code, so I think that we're going to axe it. I believe that the main reason that we've had the Win9x support in the past is because Walter wanted it, and he's not against removing it now - if nothing else because we don't have a way to test it. Certainly, if the pull requests for removing Win9x support are solid, I'll probably merge them in. I'd prefer that some Windows devs look at them first though. - Jonathan M Davis
Jan 26 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 23 January 2012 at 00:24:39 UTC, Jonathan M Davis 
wrote:
 So, I really think that we should say that we don't support 
 pre-Win2K, and I'd like to say that we don't support pre-XP, 
 but I don't think that it hurts us any to say that we support 
 Win2K.

An example of system requirements for a .net application: http://msdn.microsoft.com/en-us/goglobal/bb964665
Jan 27 2012
prev sibling next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 27, 2012 20:46:17 Kagamin wrote:
 On Monday, 23 January 2012 at 00:24:39 UTC, Jonathan M Davis
 
 wrote:
 So, I really think that we should say that we don't support
 pre-Win2K, and I'd like to say that we don't support pre-XP,
 but I don't think that it hurts us any to say that we support
 Win2K.

An example of system requirements for a .net application: http://msdn.microsoft.com/en-us/goglobal/bb964665

So, Win2K+, which is probably what we'll be doing. It should be noted, however, that that's a .NET 2.0 application, and they're up to at least 4 now, so I don't know how that affects things. In general though, as I understand it, there's very few API calls which are XP-specific. Win2K and Vista are where the biggest changes are. So, if you're supporting XP, you probably might as well support Win2K. - Jonathan M Davis
Jan 27 2012
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
On Friday, 27 January 2012 at 21:52:39 UTC, Jonathan M Davis 
wrote:
 So, Win2K+, which is probably what we'll be doing. It should be 
 noted, however, that that's a .NET 2.0 application

And it works on a good range of oses and does useful and pretty nifty things. And, you know, it will take ages before phobos could become comparable to .net framework 2.0.
Jan 28 2012
prev sibling next sibling parent "Jordan Miner" <jminer7 gmail.com> writes:
I feel that libraries and especially compilers should support 
older systems. I don't like when a library or compiler limits 
what system my program can run on. I'm writing a GUI library in 
D, and I plan on supporting Windows 2000.

In this case, I don't mind dropping 95/98/Me support. They didn't 
have protected memory and being able to rely on the Unicode 
functions is great. Not to mention that MSDN no longer says what 
functions are available on 95/98/Me. But I hope that D will 
support Windows 2000 for a while.
Jan 28 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/28/12, Jordan Miner <jminer7 gmail.com> wrote:
 But I hope that D will
 support Windows 2000 for a while.

Aren't you already blocked with Win2000 support? http://d.puremagic.com/issues/show_bug.cgi?id=6024
Jan 28 2012
prev sibling parent "Jordan Miner" <jminer7 gmail.com> writes:
On Saturday, 28 January 2012 at 21:39:32 UTC, Andrej Mitrovic 
wrote:
 On 1/28/12, Jordan Miner <jminer7 gmail.com> wrote:
 But I hope that D will
 support Windows 2000 for a while.

Aren't you already blocked with Win2000 support? http://d.puremagic.com/issues/show_bug.cgi?id=6024

I've been using D1 bundled with the last released version of Tango (so very old). It has been working with Windows 2000. But I plan on porting to D2 before long and hope that that bug is fixed by then. Looks like it will be.
Jan 30 2012