On 12 Oct 2010 at 8:49, Phil Daley wrote: > At 10/12/2010 08:29 AM, David W. Fenton wrote: > > >> If a program calls into 64-bit Windows for a IE browser session, > the >> 64-bit browser comes up, not supporting Flash. > >If a program > calls other applications in a way that overrides a >user's choices > about default browser, and uses IE (even if the user >has FireFox or > Chrome or Safari or Opera defined as their default >browser), then > the problem is not with Flash or Windows, but with the >programmer > who isn't doing things right. > > No. You don't appear to know much about coding.
!!!! You're the one who has repeatedly posted COMPLETELY WRONG information about 64-bit Windows here on the Finale list, not me. > The problem is in the Microsoft API for help file calls. Help files don't use IE, they use the Microsoft HTML Help engine, which may or may use IE for rendering (I don't know). And a help file call is not a WINDOWS API, but a Microsoft API, and that means the issue is not with Windows, but with Microsoft's help engine. These are crucial distinctions, and as someone who is criticizing someone else for not appearing to know much about coding, you're remarkably sloppy in your terminology. > When the call is made on 32-bit Windows, it launches 32-bit IE. > > When the exact same call is made on 64-bit Windows, it launches 64-bit > IE. > > You shouldn't have to recode for different platforms. Huh? Of course you sometimes have to code for different platforms (e.g., long pointer data type, for instance, which can have a vastly larger range than plain longs on 32-bit Windows), but it entirely depends on the language you're coding in, and the IDE and compiler you're using. Should your compiler take care of these things for you? It's one point of view that it should, but many prefer that it not. Certainly the results of having your compiler automatically "fix up" API calls for the 64-bit memory space are not as predictable as coding for it yourself, so I personally prefer the way MS has handled it, which requires minor adjustments to code. You may disagree, but this isn't exactly a surprising thing that there are incompabilities. The 64-bit transition so far has seemed to me to have gone better than the 32-bit one. That is, a lot of software failed to run on Win95 (let alone WinNT 4), and in almost all cases it was because the developers were ignoring Microsoft's longstanding standards for how to code to the Windows APIs. I expect that 32-bit software that fails to run in the 32-bit subsystem in 64-bit Windows is badly written (there is no longer the excuse of being tied to hardware), just as a lot of the software that failed to work under Vista's UAC was badly written (i.e., the developers had been ignoring Windows security standards that had been in place since 1999). Now, some of that badly written software might very well come from Microsoft (e.g., the Microsoft APIs for their help system, perhaps), but Microsoft != Windows, and the discussion was about 64-bit Windows, not Microsoft in general. Likewise the issue was not about programming, but about USING 32-bit software on 64-bit Windows. I don't believe a single one of your "advisories" is valid for end users. And, in fact, many of them aren't even valid for programmers (e.g., your completely erroneous comment about Access, i.e., Jet/ACE). Your comments were alarmist and almost wholly unfounded in fact. They were certainly misleading and really did not help the discussion, in my opinion. -- David W. Fenton http://dfenton.com David Fenton Associates http://dfenton.com/DFA/ _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
