The same 64-bit vs 32-bit debate with a bit of Apple sauce thrown in for good measure

[MrSinatra]

split from http://forums.winamp.com/showthread.php?t=335960

I see this too. For me, my collection is still small enough that I don't need to worry about exceeding the addressing limit for 32-bit apps. Those in danger of this, will have to paid more attention to memory usage and restart WA to avoid a crash, when usage gets too high. I fear solving this will be harder given WA's early design decisions.

well, whenever 64bit is suggested, all the nattering naysaying nabobs of negativity kill it, so i'm not sure that will happen unless windows drops 32 bit, which i hope they do. still, releasing ram should be np in 32bit.

[Batter Pudding]

well, whenever 64bit is suggested, all the nattering naysaying nabobs of negativity kill it, so i'm not sure that will happen unless windows drops 32 bit, which i hope they do. still, releasing ram should be np in 32bit.

Microsoft have only just dropped support for 16-bit applications. So the 32-bit ones are going no where for at least a decade. Really is no need to rebuild a perfectly working 32-bit application into 64-bit. (Topic of another thread).

The odd counter that is now overflowing can selectively be changed to 64-bit. Even the ancient 16-bit applications can handle datatypes with 64-bit, 256-bit numbers and bigger numbers.

Trouble is, as you fiddle with something "small" like a counter, this can sometimes have nasty knock on effects.

This is not "naysaying nabob" talk, this is plain programmer common sense. The only thing a native 64-bit application would gain is letting this memory issue run away into bigger and bigger amounts of RAM.

[MrSinatra]

i'm not qualified to argue over the finer points of programming, so i'll let that lie. however, what i can do is point to apple, who imo, seems to be rapidly overtaking windows in every way:

http://en.wikipedia.org/wiki/OS_X_Mountain_Lion

note that OS X is not only itself 64bit and requires a 64 bit processor, but in ML will now require a EFI64 bit bios. in other words, apple is dropping 32 bit completely.

i have also read that adobe CS6 will not run on 32 bit macs.

if windows is going to wallow in old technology for the next decade or more, i think that says everything you need to know about them. i am glad winamp has finally moved on to other platforms like mac and android, b/c windows seems doomed.

my hope would be that if the dev team can do a brand new, from scratch implementation of winamp for mac or for android, they can do the same thing with a 64bit windows version, and completely cut ties with the current incarnation. there are pros and cons to this, but the legacy drawbacks of the current implementation are real and there, and at some point it will have to be done anyway, regardless of if its now or ten years from now.

the current devs know more than anyone all the current limitations and bad design choices of the current implementation, so what i would urge them to do is post this list publicly and solicit feedback about any they missed, and collect this info for at least a year or more, the point of which would be to devise a new incarnation of winamp that is as future proofed as possible and totally bulletproof to strange vagaries and other weirdness.

this is not unprecedented. not only have new winamps now been made for mac and droid, but when winamp 3 was determined to be crap, they scrapped it and built 5 on 2's design.

i would favor a very long 64bit beta process, where the basic core features were slowly added over time and betas were made available to folks like us to put thru the paces. i would even be willing to pay a nominal monthly fee to be part of the beta process, as long as my feedback was truly given consideration.

in addition to killing off all legacy disadvantages, and creating new bulletproof paradigms, (to the extent one's experience and knowledge from what they've learned under 5 is possible), i would like to see publicly stated goals of a new winamp, such as plugin verification and version checking, error reporting, truly modular skins, etc. maybe we should start a thread where the idea is to state what the goals of a next gen winamp should be?

what apple has done, imo, is shown that if the current product is good enough, you do not need to worry about legacy support. you can just push ahead and people will follow.

[Batter Pudding]

tl;dr. If you were to follow the Apple mantra you would not have a 15 year old Winamp. Microsoft is about legacy support. Apple is about buying new kit. This is a discussion for a different thread. If there is a mod reading this I suggest this 64bit conversation is split off to a new thread so as not to confuse this original issue any more than is needed.

[MrSinatra]

tl;dr. If you were to follow the Apple mantra you would not have a 15 year old Winamp. Microsoft is about legacy support. Apple is about buying new kit. This is a discussion for a different thread. If there is a mod reading this I suggest this 64bit conversation is split off to a new thread so as not to confuse this original issue any more than is needed.

i agree, starting with your post 126. i also agree that apple does what it does b/c its about buying new kit, but that hardly has been an unsuccessful strategy. microsoft is, imo, on the verge on becoming completely ghetto, if not dead altogether.

i disagree that there would not be a winamp. itunes has gone thru all these changes, and been just fine. so could winamp.

[DrO]

64-bit is not the all singing all dancing thing which everyone seems to think it is. it can be if things are actually done which use the additional aspects it can allow but Winamp just doesn't really make much use of it.


sure start everything over again and do it right but then watch at the split of people who refuse to use it because their precious plug-ins don't work anymore. it then just becomes 2.x vs 5.x or 2.x vs 3 all over again and that just doesn't help things. Winamp3 did a lot of things better and actually in the manner MrSinatra mentions but it was too much for the hardware at the time and that's what helped to kill it. 5.x contains a fair bit of things from Winamp3 via the modern skins and also internal services and yes the legacy aspect is a hinderence but it can be worked around as has been done - why else do we have 3 different ways for a plug-in to add itself into the media library tree?


"oh but 3rd party devs can update their plug-ins and it'll all be ok" - what 3rd party devs? Winamp proper thrived in a time when people would make plug-ins, those days are gone and as Android, etc is where it's at now for all of the cool kids, that's where the development focus goes and that means little to no work on Winamp proper itself.

maybe it would be best to go the Android route and just drop plug-in support and just annoy people by waiting on things to be added into the core which isn't guaranteed to happen or doesn't do it "right" (which was why plug-ins were done in the first place).


and if someone wants to suggest a title then i'll change it.

-daz

[Batter Pudding]

iTunes has gone "through the changes" because it is the store front to sell Apple products. It is very different to Winamp. iTunes is shop first, music player second. Winamp does so much more.

iTunes does not have to support a community of plugin developers. Winamp does. And some of the most useful plugins are ancient. Most of the code in Winamp is probably just as ancient, but works brilliantly. Why reinvent the wheel?


Apple make great kit. Don't think I am anti-apple. I have written software for both platforms. I support both platforms in my business. But as an example of a Microsoft strength I went back to some of my source code from 1998 and was able to not only recompile it without change, but I could also take the original executables I made in 1998 and run them on my modern 64-bit windows OS over a decade and a half later.

If I tried to do that with my old Apple Applications there would be no chance. Processor design has changed. And with many of the OS upgrades that Apple do they force you to replace your old software. Look at Lion - that almost without warning forced people to dump perfectly good software products purely because Apple decided to avoid the legacy support option of the older Motorola 68000 CPUs.

(Remember - inside older Apples used to be superior hardware. Now it is the same old Intel CPUs that you find in the PC market. Sitting on Foxconn motherboards just like you find in a Dell PC)


Apple is a marketing man's dream. Old Jobs was a Marketing Whizz. Who else could persuade they clients to buy expensive kit, the users then evangelize about that kit doing the sales job for them, yet the moment the new model is out they throw away the kit and buy new. Stunning business model.


In the PC world us poorer people can happily pick up ancient software and still do the job with it. I still run an old copy of Photoshop 7. Does everything I need it to do and has saved me hundreds if not thousands of pounds in upgrade costs. A different model. Microsoft just made the OS and then let dozens of other companies make the hardware and software and then the customer has the choice.

[Am about to reply to more of this thread, but can't do it tonight as I am out of time. I have beers to drink and places to be. But I do like to have a constructive discussion on this. But you can't just dismiss processor architecture in one sentence and replace it with "Well, Apple are doing it...." and then expect Developers to take the post seriously. ]

[Batter Pudding]

A title for the thread? "That old 64-bit vs 32-bit debate with a bit of Apple sauce thrown in for good measure" ?

[MrSinatra]

without responding line item, let me make a few points...

i don't care about 16 bit vs 32 bit vs 64 bit. i am simply suggesting that going to 64bit would be a good excuse to "start over" and people would just have to deal with the deprecation of plugins that ALREADY aren't being maintained. many many plugins are ALREADY kaput!

and if an older plugin really was so good and necessary, if the new environment were enticing enough, you can't dismiss the possibility that THATS what would motivate someone to redo it, or do again from scratch, (ie. another person).

there are weaknesses in the current implementation, things i have asked for that i've been told can't be done because of those weaknesses. a 64bit beta project would be a good excuse to put those things in the past. things that the competition in some cases, already does:

plugin version checker and verification
skipping of short files due to weakness between input and output plugins
more modular skin design, more control to layout, buttons, sorting, etc
ability to randomize ALL visualization plugins, not just the one loaded at that moment
multi threading and all that proc mumbo jumbo

and i'm sure you guys can think of many more.

some other benefits that could be realized in a new project, would be making as many plugins open source as possible, including open source input/output plugins, converting everything to unicode, having APIs that are consistent across the board and entice developers to make plugins, b/c the environment is a good and reliable one. (it seems like right now, 3rd party guys are demotivated in part b/c new winamps break their functions. it would be good to design core winamp such that that would almost never be the case, or less frequent than now)

i can't think of every possible angle or make the best case for this, i'm not qualified to. but being tied to the past is not a way forward. it just feels like this would be a good time to strip down winamp, and start over, and slowly build the beast. that way all the things that i see drive you crazy DrO, all the inherent contradictions in the app, could be addressed.

and i was oversimplifying the winamp3 story, i know that, but for all intents and purposes thats how it looked to the public at large. and i should also point out that i don't like apple, and until recently i hated apple, but i do think that they are realizing gains in their CURRENT PRODUCT OFFERINGS that are realized by NOT having to worry about or be concerned with legacy issues and support.

now one can absolutely reasonably say that legacy support is important and a good thing and so on, i can certainly see and concede that that is a legitimate POV, but apple is demonstrating that KILLING legacy support is the more commercially successful strategy, at least for the moment. and i think in large part that is due to the fact that the platform they offer is more attractive to more developers, simply b/c it is so uniform and devoid of legacy issues.

just my ever so humble opinion.

my subj line suggestion:

beta winamp 64, pros and cons

[DrO]

pretty much what you've described is out there, it's called foobar2000.

yes a lot of things in Winamp drive me crazy but without it, it's just not Winamp (if that makes sense).

yes a lot of plug-ins out there are 'kaput' but most of that is stemming from OS and required security updates and isn't from intentional breaking of any apis or interfaces - as most of those plug-ins never bothered to be implemented to make use of newer apis in the first place.

a number of the apis/interfaces were stabilised and improved but with the case of the input plug-ins, too many are made by people who just want to have a Winamp compatible input plug-in so it can then be used in xmplay or some other player which means doing just what 2.x provided and no more (and then i know of one who had the cheek to bitch about no metadata apis and how fb2k allowed him to provide some metadata to it etc when there has been support for it in Winamp for well over 10 years now).


i fully see the benefit of nice properly designed interfaces, proper structure to things, versioning checks (which have actually been in there since before i started doing anything with Winamp but was never leveraged) and any other number of things.


but i also come from the view of having spent more time than i can ever determine on adding and fixing things which for something that was primarily a hobby, i cannot just sit there and just go with _everything_ i've coded to make Winamp suit my needs just become negated as the 64-bit Winamp immediately causes. and if that did happen then i'd either step away from things completely or stick on 5.x and just tinker externally or even move to something else (have done that before, so it could happen again if i found something which better suits my needs).


maybe i'm holding on to much to things as is but from my view point, most 'issues' can be resolved without killing legacy plug-in support and actually a number of things can be done to legacy plug-ins without the source code to keep them compatible, it's just the time to do it e.g. wrapper plug-ins (http://www.nunzioweb.com/daz/enhancer/) and compatibility shims (http://nunzioweb.com/daz/unicodetaskbarfix/index.html)


what seems to be forgotten here is most of the areas where there are complaints e.g. library handling or skinning engine or output handling issues are just plug-ins on their own so it's not like those aspects cannot be re-implemented via a new plug-in and go that way as has been done before a number of times. the killer is getting the time and resources to do it but that's something which never changes and seems to be consistent with all of the time i've been around.


and as i've said before, Winamp is in an unfortunate state now in that it's expected to do a bit of everything to keep everyone happy and it just cannot do that (video is clearly an area that is much maligned consistently) and maybe it should have died around the 5.04-5.08 stage when everyone left but it didn't and so here we are in a situation where everyone wants different things to be added / worked on / fixed and to others it's an abomination to them to spend time on that when it should be spent on adding / working on / fixing things for them.

i'd love to have the time to work on fixing up things properly or doing things to make handling consistent or do shims (as they are a pain to do but can be quite rewarding in working out what the plug-in is trying to do) but it's not feasible and talk of starting over completely is reckless i think - if anyone's looked at the Android feedback you'll see what would be a probable response to starting from scratch especially on points like "desktop does it why can't i do it on my phone" which would be applicable in the case of going 64-bit and "why don't my plug-ins work anymore omg U sux0r d1e!!!!"


as such yes there are pros and cons but at least from my view point, the cons are far too much but then again everyone is different and maybe i've a skewed reality on the importance of plug-ins when it comes to Winamp and maybe i should just forget about them and embrace the future (whatever that may become).

-daz

[Batter Pudding]

There is one really simple issue here as well. Cost. Resources. Apple are sitting on billions of dollars so can throw money at any project. They also have followers who are used to constantly replacing perfectly good software or hardware with something new because they are told to upgrade.

In the PC world we have people on at least five different versions of the desktop OS running Winamp (win98, W2K, XP, Vista, Win7) as well as those people running it on Windows Server and its multiple flavours. Changing to 64-bit will not help those people. These are the majority of the users.

64bit conversion would cost a LOT of money and developer time. It makes a lot more sense in spending that time on something like Android instead. A truly new platform. Making a 64-bit version of such an old and complex product is a nightmare. And the Winamp devs clearly don't have access to unlimited resources.

I wouldn't be surprised if there are hundreds of thousands of lines of source code. It is hard to explain to a non-developer quite what goes into producing something like Winamp. And as DrO says, you put your heart and soul into some projects and then knowing that a large chunk of you code could not be ported is never a nice feeling.


I still don't see what the case is for starting again in 64-bit. "Well Apple are doing it" is not a sensible answer as if we followed Apple Winamp would lock into a small number of devices, throw out audio formats that will not make money, and ignore requests for compatibility. (Apple certainly would not allow a forum like this one to exist)

32bit programs run just fine in 64bit windows. It was part of the OS design. There really is no need to convert them. If your software is getting anywhere near to that 4GB limit of RAM in 32bit windows then you are doing something very seriously wrong with your data handling.


Look how many years Winamp has taken to get to the product it is now. Starting again in 64bit will mean many years of a product with dozens of features missing or buggy. And by the time those features had all been complete we probably won't still be sitting at big hulking desktop PCs any more. We are more likely to be running around with those Tablets. Which is where that Android decision will have paid off more. (And look how slow that development is moving...)


Seriously - pick a reason for conversion that would truly pay back to the user. And can be done by a very small Winamp team with limited resources. I just can't see it.

(And have you ever USED iTunes? It is horrendous and missing so much when compared with Winamp )

[Aminifu]

I once had a '69 Ford Thunderbird that I kept running for 20 years. I happily wasted a lot of time and money on that car until the cost of keeping it running became truly insane.

A port to 64-bit is not a cure-all, but Winamp will evolve or die. Afterward, it will not be the Winamp that we have loved for over 15 years. Winamp as it stands now is my favorite tinker toy. It's always a thrill finding ways around it's various 'personality' quirks and discovering new and revised plug-ins and skins. Highlighting bugs and getting them fixed is fun too.

There are alternative apps for many of the issues discussed, but with the help of devs like DrO I will stick with this old classic until it becomes 'truly insane' to do so.

[Aminifu]

It seems that the excessive memory usage stems from an old WA design decision to keep rendered artwork in memory to prevent having to re-render it. That may have made sense when rendering was slow, but rendering is much faster now (even if just on the hardware side of things) and it makes more sense (to me) to only keep images that are actually being displayed in memory.

I have no idea how hard making such a change to WA is.

I acknowledge that keeping even a small number of very high-res images in memory could use a large amount of it, so maybe some upper limit (in the software) on the artwork resolution displayed (more than 200 x 200, less than 1920 x 1080) would also be necessary.

The only thing I know for sure is that the higher an image's resolution is, the better it looks on my 23 inch (1920 x 1080) wide-screen monitor when sized to fit a tenth of the screen or larger. If statistics can be trusted, it seems most users have smaller monitors (in size and resolution). So my need looks to be outside the norm.