If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Rate Thread | Display Modes |
#16
|
|||
|
|||
XP Install (now scanners)
On Sun, 22 Jan 2017 14:22:12 +0000, "J. P. Gilliver (John)"
wrote: Every time I think I know where it's at, they move it. Looking at the embedded sentence " I think I know where it's at," it reminds me of the story of the man standing on the subway platform, asking the man next to him "where's the train at?" The reply came. "What's the matter with you? Didn't you ever go to school? Don't you know better than to end a sentence with a preposition?" "OK. Where's the train at, asshole?" |
Ads |
#17
|
|||
|
|||
XP Install (now scanners)
On Sun, 22 Jan 2017 09:43:43 -0700, Ken Blake
wrote: On Sun, 22 Jan 2017 10:00:47 +0000, "J. P. Gilliver (John)" wrote: Really? That is disappointing. I've just looked at the above page, and - though, puzzlingly, in pale grey under the button for "download XP version" - they say it works on Windows 10, 8, and 7; if it's only 32-bit, they are being decidedly disingenuous. (I suspect W10-32 is a rare beast.) And getting rare Sorry, typo. That should be "rarer." all the time. 32-bit computer are fast disappearing, and it won't be long before everything is 64-bit (or perhaps even 128-bit). |
#18
|
|||
|
|||
XP Install (now scanners)
"Ken Blake" wrote
And getting rare all the time. 32-bit computer are fast disappearing, and it won't be long before everything is 64-bit (or perhaps even 128-bit). Not exactly fast. Some people are still using 16-bit software, which was mostly replaced almost 20 years ago. And the only thing I'm aware of presently that excludes 32-bit is Adobe's Creative Suite. (Which is rental software, anyway. Good riddance to them.) 32-bit allows for numbers up to about 4 billion. It became outmoded due to things like large video files, large hard disks, and RAM capacities. The only major shortcoming of 32-bit currently is limited RAM. It will be mostly phased out over the next few years, but we're really just approaching the tipping point now -- where 64-bit is likely to be less hassle for most people than 32-bit. That's because most 32-bit software runs on 64-bit while some software is still not available in 64-bit. (When Win7 came out, IE-32 was the default because plugins were not available in 64-bit.) 64-bit allows for numbers up to about 18 pentillion. Do you really think we're going to outgrow that anytime soon? I'd say you're pretty safe buying a new computer or CPU that's "merely" capable of 64-bit. |
#19
|
|||
|
|||
XP Install (now scanners)
On 22/01/2017 10:00, J. P. Gilliver (John) wrote:
Thanks for the explanation. I think I have looked at it (or similar) at times; I tended to dismiss them as just a gimmick on what is basically a flatbed scanner. I hadn't realised they did higher resolution for the negatives. (Though, unless - which seems unlikely - the scanning head has extra sensors in just a middle stripe, _presumably_ the higher resolution, theoretically, should be accessible for full-width material too, though rarely _required_ for that.) I never tried to scan at the high resolutions over the whole platten. But from what I remember, when in negative/transparency mode, with ScanGear running and the film holder in place, the scanner becomes "intelligent", and is able to detect exactly where each negative/transparency is located on the platten (there's a special identifier slot at the top of each of the holders), and only scans in those locations. Using ScanGear, you ended up with a number of individual images depending on how many pictures were there. If you placed a whole page on the platten to be scanned, I guess the machine would realise it wasn't a film (there's be no slot in the right place), and disable the ultra-high resolution. If it didn't, you would probably end up with a file size (12Gb, I think, for an A4 image in BMP format) that would sort of spill out over the edges of the available RAM in the computer!!! It was rather clever how it worked. When I originally made up the 126 film holder, it wouldn't work. But cutting a slot in the same position and the same size as the 35mm negative holder cured that, though it couldn't identify individual frames. It scanned the whole strip as one image, which I used PSP9 to separate into the individual pictures. Very fast, very easy, and very good results despite the tiny size of the negatives. That scanner, together with a Canon iP6700D photo printer (still in daily use through Win7) were probably the best bits of kit I ever bought for a computer. jim |
#20
|
|||
|
|||
XP Install (now scanners)
In message , Mayayana
writes: [] the tipping point now -- where 64-bit is likely to be less hassle for most people than 32-bit. That's because most 32-bit software runs on 64-bit while some software is still not available in 64-bit. (When Win7 came out, IE-32 was the default because plugins were not available in 64-bit.) [] What I fail to understand is why we've accepted the principle that 64-bit machines can't run 16-bit (or 8-bit, for that matter!) software. [I'm not saying I don't understand why it doesn't: that's because of the way things have been decided.] The only "excuse" I can see for the decision is that, arguably, 3/4 of the hardware in a 64-bit system would be idle when running 16-bit software. But who cares: it's almost certainly considerably more than 4 times as fast as the hardware the 16-bit software was written for, so it ought to actually run at least as fast as it always did. (Plus, of course, modern OSs could find plenty of "background tasks" to "occupy" the idle hardware.) -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf "Outside of a dog, a book is man's best friend. Inside of a dog, it is too dark to read." - Groucho Marx |
#21
|
|||
|
|||
XP Install (now scanners)
In message , Wolf K
writes: On 2017-01-23 16:12, J. P. Gilliver (John) wrote: In message , Mayayana writes: [] the tipping point now -- where 64-bit is likely to be less hassle for most people than 32-bit. That's because most 32-bit software runs on 64-bit while some software is still not available in 64-bit. (When Win7 came out, IE-32 was the default because plugins were not available in 64-bit.) [] What I fail to understand is why we've accepted the principle that 64-bit machines can't run 16-bit (or 8-bit, for that matter!) software. [I'm not saying I don't understand why it doesn't: that's because of the way things have been decided.] The only "excuse" I can see for the decision is that, arguably, 3/4 of the hardware in a 64-bit system would be idle when running 16-bit software. But who cares: it's almost certainly considerably more than 4 times as fast as the hardware the 16-bit software was written for, so it ought to actually run at least as fast as it always did. (Plus, of course, modern OSs could find plenty of "background tasks" to "occupy" the idle hardware.) Actually, 8, 16, 32 bit software runs slower than on lower-bitness systems. A few years ago, when I still subscribed to computer magazines, one of them did a test and found that lower-bitness programs ran 5 to 10% slower than on 32- or 16-bit systems. Here's how I For the same clock rate, maybe. understand why that's so: The bitness refers to the data path width. Instructions are generally small, usually only 8 or 16 bits wide. An 8 bit program written for an 8 bit system uses one fetch for the instruction, and one for the data. A 64-bit program uses one fetch for both instruction and data. So an 8 bit program on a 64 bit machine uses more clock cycles than a 64 bit program. Have a good day, But the increase in overall speed ... even if the 64-bit machine is doing two fetches per 8-bit instruction, it can probably do it in a lot less time than the machine the software was originally written for. -- J. P. Gilliver. UMRA: 1960/1985 MB++G()AL-IS-Ch++(p)Ar@T+H+Sh0!:`)DNAf After all is said and done, usually more is said. |
#22
|
|||
|
|||
XP Install (now scanners)
"J. P. Gilliver (John)" wrote
| What I fail to understand is why we've accepted the principle that | 64-bit machines can't run 16-bit (or 8-bit, for that matter!) software. Running 32-bit on Win64 requires what they call a shim. Likewise with running 16-bit on Win32. The processes have to be run through a translator. What happens with software is mostly calls to system API functions. The OS is the platform that provides the functionality. With a 64-bit system the API functions will be 64-bit. The standard for data or pointers being passed around will be 64-bit. In other words, the default numeric value used to communicate will be 8 bytes rather than 4. Example: RegQueryValueEx. A common system function used to get the data of a Registry value. There are lots of ways to get Registry values, but it's likely that all of them are using RegQueryValueEx at some point. The first parameter in that function is a handle to the key, which has been opened previously. The second parameter is a pointer to a string value that holds the name of the value to be returned. It's an address in memory where the name has been stored as a string of character values. The function has 6 parameters. Advapi32.dll assumes the data sent in the function call is the right parameters. But in 32-bit that data only takes up 24 bytes (6x4), while in 64-bit it takes up 48 bytes (6x8). If 32-bit software calls 64-bit advapi32.dll to use that function it passes the handle as a 32-bit numeric value and the string pointer as a 32-bit value. Without the shim to handle the call, it would be passing both of those values as the first parameter, the 64-bit handle. There are 6 values in all. 32-bit software will pass 6 32-bit values. 64-bit software will pass 6 64-bit values. If the 32-bit software is not caught and handled it will pass corrupt data for the first 3 values and the second 3 will end up being addresses in unallocated memory. The program will crash, if for no reason than that it's trying to "illegally" access unallocated memory. But it will also crash because the parameters will be nonsense. | The only "excuse" I can see for the decision is that, arguably, 3/4 of | the hardware in a 64-bit system would be idle when running 16-bit | software. Not really. It depends on what it's doing. In general, the higher the bit-level, the more waste. In the example above, the 64-bit function call requires twice as much memory, but the parameters may not actually need so much memory. It's likely that all the parameters can be fit into 32-bit (4-byte) numeric values, which would mean that all those extra bytes are not used. But I suspect a 64-bit CPU works fastest with 64-bit values, which would mean that the 32-bit call, while more efficient, might actually be slightly slower. (Of course, at 3-4 billion operations per second that's not a big deal. And the savings in RAM might arguably make up for that, depending on the situation.) |
#23
|
|||
|
|||
XP Install (now scanners)
On Mon, 23 Jan 2017 20:17:59 -0500, "Mayayana"
wrote: "J. P. Gilliver (John)" wrote | What I fail to understand is why we've accepted the principle that | 64-bit machines can't run 16-bit (or 8-bit, for that matter!) software. Running 32-bit on Win64 requires what they call a shim. Likewise with running 16-bit on Win32. The And there was a shim for running 16-bit on 32-bit. It would have been nice if that shim had been continued in 64-bit. I have some 16-bit software that I would prefer to be able to run directly. [snip] Sincerely, Gene Wirchenko |
|
Thread Tools | |
Display Modes | Rate This Thread |
|
|