I have a WEC7 powered machine and instead of the Explorer shell I have loaded the Taskman shell instead.
But the SIP (Software input panle) is behaving strange.
When I click a teck box, the SIP is shown for a few seconds and then it is hidden again.
On a WindowsCE 5.0 there are no problems.
Thomas
It may be that the SIP relies on Shell_NotifyIcon being supported and successfully called. This is the API used to include icons in the tray bar. Its implementation relies on a windows with a specific class and title so you may be able to copy the code needed from explorer and include it in your custom version of taskman.
But the best thing to do would be trying to debug the SIP using platform builder.
As far as I know the code for the virtual keyboards is available. I don't remember about the rest of the implementation but, in any case, trying to run it in debug mode may lead to some hints about the issue.
Related
I have a solution with a C# XAML windows store app and a WinRT component which exposes C++ AMP code. A reference from app to component is set up and I can run this and with mixed mode debugging I can step into the win rt component.
I can however not select the "debugger type" of "gpu only", which launches debugging with the sotware emulation gpu debugger. I can select mixed mode and debug both the c# app and the c++ rt component, but gpu is not available, so I can't step into the actual parallel_for_each code block of the kernel.
If I use a C++ XAML windows store app as the host, I can easily enough select "gpu only" as the debugger type.
One solution is to build and launch the solution (C# app+C++ component) without debugging and then manually go under debug/attach to process and find my running process, select gpu degbugger and attach. That actually works, as long as I manually ensure to use the correct accelerator.
Since I can do this debuging in a roundabout way by manually attaching, it seems obvious it should be able to work by the normal F5 run and debug, which essentially does the same thing in an easier way.
I would be very interested in hearing about how this could be setup to work as usual and what the reason for my difficulties is.
Nb. I had a post about this with a different wording and tags because I didn't really understand the problem and workarounds then. I deleted that post and wrote this on instead.
I'm developing a filter driver which works on top of an input device. Notably I'm testing it on my development machine (and yes, I know this is a bad idea).
On Windows XP whenever I needed to reload the filter driver, I'd just execute a batch file that would disable-enable the relevant devices through devcon, thus cause my filter driver to unload and reload.
However, on Windows 7 there seems to be a specific measure built against disabling the input device which your session is using. The option simply becomes unavailable in the Device Manager and even devcon no longer works. It does work from a remote desktop session, along with the kernel debug print "Trying to disable physical device not enabled in this session." (which hints that something explicit is allowing me to do this).
Is there a way to disable this functionality of Windows 7? Or perhaps a workaround you can offer to run my disable-enable batch file from an unrelated session?
Using Sysinternals psexec to run dpinst.exe works around this limitation. (Not sure why, since the DpInst UI is still being displayed.)
I have some customers/candidate who complained that my program doesn't work on their Windows 7 64 bit version (confirmed with screenshots). The errors were strange, for example:
in the trial version i am
getting a error message whenever i
click on \"mark\" \"delete\" \"help\".
error msg is: Access violation at
address 0046C978 in module
\'ideduper.exe.\' read of address
00000004
windows 7 ultimate 64bit. i7 920
#2.67GHz 9gb or ram
'Mark', 'delete' and 'help' are just standard TToolButton on TToolbar.
The other example is failing to get a thumbnail from IExtractImage.
I have told them to try Compatibility mode but still doesn't work.
The problem is when I tested it on Windows 7 HP 64-bit on my computer (which I've done it before released it actually) it just works fine! So I don't know what causing it
Do you have any advice ?Are different Windows package (home basic,premium,ultimate,etc) treating 32 bit prog differently ?Are the newer version of Delphis (I use 2006) more compatible with 64 bit Windows ? Do I need to wait until 64 bit compiler out?
Thanks in advance
Your best bet in my opinion is to add MadExcept or EurekaLog or something similar to your application and give it to the customer to try again. MadExcept will generate log with stack trace, which will give you a clearer view of what is happening there.
To answer 2nd part of the question, 32bit Delphi programs work fine on 64bit Windows 7. I think it's more likely you have some memory management problems and the customer just happens to stumble upon them while you don't. Use FastMM4 to track those down.
Your applications is trying to access an invalid pointer. Changing environment may surface issues that are hidden in others. Check your application, and use FastMM + JCL+JCVL/MadExcept/EurekaLog to get a detailed trace of the issue. Some Windows APIs may have some stricter call requisites under 7 and/or 64 bit, but we would have to know what your app actually cals.
A free alternative to MadExcept is JCL Debug stuff. However it is less thorough and doesn't include the cool dialog box to send the stack trace to you via email, or as a file you can attach and manually email.
MadExcept is worth the money, and it is free for non-commercial use. You could try it first on your own PC, observe its functionality, and be sure it functions the way you want, and then buy it.
If buying Delphi is worth it (and it is!) then buying mad Except is a no brainer. But if you insist on rolling your own, JCLDebug (part of jedi code library) is also pretty nice.
Give them a stripped down version of your app and see when the problem goes away. I am betting it is your code as I never had any problems with my (hundreds of) W7/64 clients.
I'd be willing to bet it's an issue in your code. The reason it's failing on your customer's machine and not yours is that your machine probably has the default Data Execution Protection (DEP) enabled (which is turned on only for essential Windows programs and services), while your customer's computer is actually using DEP as intended (turned on for all programs and services).
The default setting (which is compatible with older versions of Windows, like 95/98/ME), allows software to execute code from what should be data segments. The more strict setting won't allow this, and raises a system-level exception instead.
You can check the settings between the two by looking at System Properties. I'm not at a Win7 machine right now, but on WinXP you get there by right-clicking on My Computer, choosing Properties, clicking on Performance Options, and then selecting the "Data Execution Prevention" tab. Find it on Vista/Win7 by using the Help; search for Data Execution Protection.
The solution, as previous answers have told you, is to install MadExcept or EurekaLog. You can also get a free version as part of JEDI, in JCLDebug IIRC. I haven't used it, so I can't vouch for it personally. I've heard it's pretty good, though.
If you don't want to go that route, set a breakpoint somewhere in the startup portion of your app (make sure to build with debugging info turned on). Run your app until the breakpoint is hit, and then use the IDE's Search->Goto Address (which is disabled until the breakpoint is hit). Enter the address from the exception dialog (not the one that's almost all zeros, but the 0046C978 address, prefixed with $ to indicate it's in hex) as in $0046C978. You'll probably end up in the CPU window looking at assembly code, but you can usually pick out a line of Delphi code of some sort that can sometimes give you a place to start looking.
In addition to all previous suggestions, I'll add the difference in accessing Registry under WOW64 compared to Win32. If your application is accessing Registry to read or write some settings, you should be aware of this. First, take a look at this and this page in the MSDN. On this page you will find 2 flags that determine the access you get to Registry from 32- or 64-bit application. KEY_WOW64_64KEY is the one that you should use.
In any case, I agree with others about using madExcept (or any other similar tool) to be able to find the exact cause of your problems.
I am starting to design a DMO to run from inside a windows media player activeX control in Internet Explorer.
is there any reason why using windows named pipes from inside the DMO wouldn't work?
user permissions/privilages/ kernel mode stuff?
Thanks :)
Roey
I have not tried it but I can't think of any particular reason it could not work. However, keep in mind that starting with Vista Internet Explorer runs as a low integrity level processes so any pipe you connect to will need to have it's access control set accordingly.
I have done this from a FireBreath plugin (activex control on IE, npapi on others) and the only thing you need to keep in mind is that activex controls in IE are often running in low integrity mode, so you need to make sure you set the ACL mask on the pipe correctly. As long as you have it configured correctly, it works fine.
Windows XP Embedded is missing the NULL or "NUL" device. For one thing, Visual Studio seems to require it and trying to build a project aborts with a PRJ0015 error.
Anyone know how to configure an XPe image to include support for the NUL device?
"Null Device Driver" is available in the XPe Target Designer, but it's normally hidden. Apparently each component has a visibility level, and if it's lower than that set in the Target Designer options (Tools->Options), it's hidden. Null Device Driver is at level 200, so I set the level to 100 and could see it and install it.
There's another important situation where you're going to want the NUL device: if you're installing some or all of the Cygwin UNIX solutions for Windows. In particular, if you're doing something like, oh, I don't know, to pick a completely random example, trying to put an SSH server on the damned thing so you can, just on a lark, say, log in and maintain it.
That's right-- Cygwin actually maps its UNIX /dev/null device to the Windows NUL device. You know, for maximum compatibility. Just in case the platform-specific implementation of IMMEDIATELY THROWING DATA INTO THE TOILET AND OBLITERATING IT, NEVER TO BE SEEN AGAIN, UNTIL THE HEAT DEATH OF THE UNIVERSE, happened to be novel and innovative.
While cygwin will INSTALL without NUL available, it will not, in fact, actually enjoy a typical work day. This is most evident the first time you try to launch a bash shell, and notice a slew of error messages about /dev/null resulting in no such file or directory errors. One presumes the device is perhaps actually just an NTFS link, but who knows.
In any case, the fix is to add the "Null Device Driver" component, helpfully located under Software -> System -> Other, a surprisingly small category which also contains such useful components as Internet Checkers, the Schedule Service Command Line Utility, the 1394 Kernel Debugger Support Library, EBCDIC support for Microsoft Bob, some cheat codes for Zork, and the code pages to say "(A)bort, (R)etry, (I)gnore, (F)ail?" in Muppet Swedish ("(B)ork, b(o)rk, bo(r)k, bor(k)?")
Hope this helps,
Matt "Breakpoint" Heck
Running Visual Studio itself on XP Embedded doesn't seem like it'd be supported. You should build on a full OS and then just deploy your application to XP embedded.