Please do not be so arrogant in your response !
The point is mainly that we want to use 64bit software but we are stuck with 32bit version because some plugin we use are not ported to 64bit. A technical solution seems to exists and is not available. M. Ghisler want to wait for plugin to be ported or regenerated..... But if the sourcecode is lost, the plugin author do not care about TC anymore,... We are forced to wait for nothing !
(I even know some IT people that continue to install windows XP 32bit for some large customer because it pay the bills )
csmarshall wrote:
With all due respect - I know more people doing maintenance work as described than users that use a 64bit OS but still use old-school 32bit plugins instead of using 64bit tools that are specialized for their job. 32bit was YESTERDAY and trying to cling on to old plugins is just as pathetic as still wanting to use Internet Explorer 5 simply because you are "used to the interface".
With all due respect some still use 16 bit utilities daily wrapping them around DosBox because 32 bit versions were never made. Claiming 32bit was YESTERDAY is downright laughable and pretty much proves you do not have a clue about what you are talking about
Krawhitham wrote:With all due respect some still use 16 bit utilities daily wrapping them around DosBox because 32 bit versions were never made. Claiming 32bit was YESTERDAY is downright laughable and pretty much proves you do not have a clue about what you are talking about
So you want us to believe that just because you know a few folks that still use 16bit apps, the development towards newer technology is nonsense and people stating the point that development progresses have no clue what they are talking about? Your effort of defending their unwillingness and incapability of evolving drives me to tears, you obviously completely missed the point of my post.
You are talking about a few exceptions, people that for some reason stuck "back in time", simply because they never made the step and progressed. And why was that? You say yourself - 32bit apps (and now 64bit apps) were never made. Is that my fault? Or that of the people that use them? I would think that certain applications remain in the "stone age" as no person actually sees the *need* to evolve them.
That however is not the same as what will happen here: some folks here would rather patch around and spend endless hours in an effort to implement 32bit plugins in a 64bit world ... instead of steering the effort towards rewriting the plugins for 64bit. It is not like the 32bit plugin code, even if lost, is such a large secret as the interface towards and from TC is known and documented. Work, yes - impossible? No.
I dare say that a 32bit 'back in time' interface is plain stupid.
Before we start a flaming war or a huge dispute on 32 against 64 bit, I would like to point out that many people are still using older hardware. I would personally not recommend Win7 x64 for a machine with only 2Gb (or less) on board. So there seems to be a need for 32 bit OS and TC/plugins. This does not mean I am against 64 bit versions, but as long I have to access machines with 32 bit OS, I'll stick with the TC x32 version, since the x64 won't work there.
Regards, EricB
Edit: by access I mean either using an USB stick and TC portable, or running TC natively on a 32 bit OS, beit XP, Vista or 7 (did not use 8 yet).
2csmarshall
If you take a search on this forum you will find tat even Ghisler was against 64bit TC because it gives not enough improvements for filemanager.
It is also not always the matter of being anti-tech, sometimes it's about money, sometimes personal preferences - if it works perfectly well, should anybody truly be forced to change just for the sake of changing?
On the other hand: yes, it may be stupid to live in the past but you can't live in future either. Win8 is now the most recent Windows version, can you really allow yourself to forget all of your clients (or friends) because they can't keep pace?
And what is wrong with all of that: for many years no one cared about 64bits or… SVG and now everyone is "yay, 64!", "yay vector graphics for web"… Sudden change of heart or hypocrisy?
EOF
"When we created the poke, we thought it would be cool to have a feature without any specific purpose." Facebook...
@EricB / fenix_productions: Just to set that straight, I never implied or intended a "war" regarding 32<->64 bit, that in itself would be nonsense. If people have older hardware - for whatever reasons - it is fully understandable that such a machine is 'old school' in terms of not being the newest high-tech doo-daa. My girlfriend revamped an old PC with a VIA Pro200+ processor to run with Linux Mint 13 XFCE - she only needs that machine to run OpenOffice with a few spreadsheets, and WinXP slowed the machine down too much. Works fine, 32bit, 1280x1024 resolution, no problem. She is one of the users that does not need a 64bit machine.
My point was that some people have a 64bit machine with TC 64bit and demand that somebody gives them a possibility to re-use 32bit apps in it. As pointed out, plugins may be quite nifty stuff, but if I do not get a matching solution in 64bit that will run in TC 64bit (because the original coder still uses 32bit or simply lost interest), I look elsewhere to find a matching standalone application that can do the job. There is no reason at all to stay around and wait for a solution in form of a 32bit sandbox for TC 64bit.
Examples:
32bit AnyTag / Multimedia Factory plugin - why not simply use the (32bit) standalone Mp3tag v2.53? It is faster than AnyTag, supports the same container formats, works with 50,000+ files and in multiple Unicode directories (both of which either crashed AnyTag and/or MMF), allows various export and file manipulation possibilities and is free of charge. It does not run *in* TC (as a plugin would), but it works fine with drag&drop and gets the job done, fast & easy.
32bit OfficeView plugin: relies on the MS converters. People working with (old or vintage) Word docs know that those converters and even the newest WinWord is incapable of importing old MSWord & some WinWord documents. Unlike the free of charge (32/64bit) OpenOffice/LibreOffice, which at least contains file and text structure and allows me to read and convert an old MSWord/WinWord document that MS Office corrupts beyond belief or simply denies access to.
What ticks me off is that some people in question state how "vital" the 32bit plugins would be for their work - as if they can't live without them. I don't know how some people tick, but if I have a workload to accomplish, I would rather get it DONE instead of waiting for ages, spending my time whining about missing plugins that I actually do not need as there are other solutions available.
Especially when a 32bit sandbox would be nothing more than open support for their laziness, at the same time 'downgrading' parts of a perfectly working 64bit application like TC. One simply has to accept the fact that every interface will cause problems/bugs, and shortcomings of the 32bit sandbox in itself will most likely impact on TC 64bit itself. Why ruin the experience of many standard users just because a few users want to run 32bit plugins in a 64bit surrounding?
One may state that the common user will not use the 32bit plugin system anyway, but discussions thereof and bug reports regarding it will be found here. And the inclusion of the sandbox alone (if used or not) may result in a higher overall workload and more bug-eliminating work for Herr Ghisler. Many negative aspects involved - merely to please a few users that believe they need to work with obsolete plugins?
csmarshall wrote: As pointed out, plugins may be quite nifty stuff, but if I do not get a matching solution in 64bit that will run in TC 64bit (because the original coder still uses 32bit or simply lost interest), I look elsewhere to find a matching standalone application that can do the job. There is no reason at all to stay around and wait for a solution in form of a 32bit sandbox for TC 64bit.
I fully agree with the previous statement. TC is my tool of choice, but if something cannot be done easily using TC, I'll find something else which does the job. In (quite) some cases a standalone application is better suited for a particular job.
MP3Tag is indeed a good example. You can even use it from within TC using Context menu. Drag and drop would also work of course.
csmarshall, thanks for elaborating further on your views on a 32 bit sandbox for TC x64. Native 64 bit plugins is better, for sure, but if someone like Merix would like to create an (optional) wrapper for some 32 bit plugins, he or she is free to do so. I do not expect Christian to be heavily involved, most likely he has other things higher up the list.
I've often wondered why some plugins even existed -- e.g. the RegistryViewer/Editor. I have to believe that MS has a working solution with their RegEdit ... but I'd be hard pressed to "trust" a TC plugin to deal with the registry.
I've been primarily using TC 32bit on Win7 x64 -- though mostly due to my own AHK code not being compatible with TC x64's usage of "Window##" for all of it's interface controlID's. Even if I took the time to try to rewrite it all now, one really can't be sure which control Window7 is since the controlID's will change all depending on which GUI elements you enable/disable/or are visible at any given point.
*BLINK* TC9 Added WM_COPYDATA and WM_USER queries for scripting.
Balderstrom wrote:I've often wondered why some plugins even existed -- e.g. the RegistryViewer/Editor. I have to believe that MS has a working solution with their RegEdit ... but I'd be hard pressed to "trust" a TC plugin to deal with the registry.
I've been primarily using TC 32bit on Win7 x64 -- though mostly due to my own AHK code not being compatible with TC x64's usage of "Window##" for all of it's interface controlID's. Even if I took the time to try to rewrite it all now, one really can't be sure which control Window7 is since the controlID's will change all depending on which GUI elements you enable/disable/or are visible at any given point.
By the way it's a big problem for me, since now my ahk script doesn't work. How come such a non clever decision was made as to use dynamic names for classNN for toolbars? wtf? why not static IDs at least for the built-in ones?
I've always wondered too why Delphi uses dynamic control IDs instead of static ones, it is a real pain to distinguish them, even standard OK/Cancel buttons can't be detected by ID...
HAL 9000,
TCx32 is compiled with Delphi which uses human-readable window class names but random control IDs.
In Windows OK button always has ID 1, Cancel has ID 2 etc, so you can easilly find button if you know its ID (it is much better than find it by class - IDs are unique within same window), but in Delphi same button has new ID every time you recreate dialog.
nvm, I thought the script I used works with x32 and doesn't work with x64 because of in x32 there were static classes for panels, but I was wrong.
I'll take a deeper look into that script now, since I've switched to TCx64 and so I have to adopt the script somehow, but that's all is uninteresting off-topic here.
That's correct, TCx32 uses constant class names for all controls (buttons, toolbars, panels etc), and they are human-readable as I said ('TButtonBar', 'TDrivePanel').
But in TCx64 most controls (toolbars, panels etc) have same class name 'Window', so it is impossible to find them by class names.
