I Need to know if my file was accessed or not so I used QFileInfo::lastRead()...
That is what the docu said:
"On platforms where this information is not available, returns the same as lastModified()."
Is there any possibility to fix that for Windows (ntfs), or is there a list which holds all the filesystem types or systems for that QFileInfo::lastRead() works?
resp. is there any walkaround due sys/stat.h (?? I thought - works only for x16 and x32 ??)
i got x64 but I´m not sure.
Thank you in advance!
Matthias
Related
I need to use the debug command in Windows 64x for learning purposes. When I type the command debug in the cmd, I get the following message:
'debug' is not recognized as an internal or external command,
operable program or batch file.
As I understand from some previous posts that debug does not work in 64x systems. Is there any work around for this issue?
EDIT:
I am trying to write assembly code for learning. I am not allowed to use any other option for writing assembly code. I have to use DEBUG.
debug.exe is not available in any of the 64 bit windows versions. What are you trying to accomplish? One option for you may be gnu debug - http://www.sourceware.org/gdb/
I know this is an ancient thread, but others might have the same question.
In general to use legacy software, the CLEANEST way to do it is to use the build in Hyper-V. And then have PC-DOS 3.30 (or any suitable 16 or 32 bit OS) on that.
Make sure to use a DYNAMIC disk (vhdx). This allows the disk to be mounted in Windows simply by clicking the vhdx (when not in use by Hyper-V - no sharing), so this allows for simple transfers, without complex net-setup.
There are other alternatives such as DOSBOX, though to my experience their emulation have some bugs (e.g. on the ancient FCB-system - older than file-handles)
I know it's a very long answer, but I just saw your post now. Use the vDosPlus (http://www.vdosplus.org/) or vDos (https://www.vdos.info/) software to run 16-bit (MS-DOS) programs on Windows 64-bit.
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 recently wrote a native NT registry editor for Windows, and ran it on Windows 7. To my surprise, in addition to the two standard root keys, MACHINE and USER, that are present on Windows XP, there was also a mysterious key named "A", that cannot be opened in any way, whether by permission changes or backup privileges or otherwise:
Does anyone know what this key is for? I don't believe it's for any software, because it was there before I installed anything on the machine, and I believe I saw it on another fresh installation as well. It's rather very suspicious, and I'm curious as to why it's there. (If I'm curious enough, I might end up writing a driver to open it up without a privilege check, to see what happens!)
(I wasn't sure whether to put this on SuperUser or StackOverflow, since I think it could go in either one. I could be wrong, though; sorry if this isn't the appropriate place.)
Edit:
If forgot to say, I don't believe you can even see this key using the Win32 API, like RegOpenKey -- you have to use the native API like NtEnumerateKey instead.
Here is the comment from one of our driver writers: "DISCACHE.sys driver seems to be caching system file attributes and using \REGISTRY\A in an undocumented way. This driver is part of the kernel so it can load any hive wherever it wants."
Interesting...
The key indeed can be opened with a relative path, but not with an absolute path.
And it seems to contain information about all file systems and whatnot. Looks mysterious, indeed...
I am trying to create a software like Ibackup.com. However, I am not sure how to make the software so that it'll map as a local Harddrive. And i am not sure where to start researching on this. Someone please give me some pointers.
I can point you to Dokan ( a user filesystem for windows like FUSE on linux), You install the driver then write the appropriate software for replying on IO request.
On a more complex answer you have to work with the NT DDK to write a driver that would be your software for being a filesystem (look at IFS: installable file system ), note that it is very complicated to work with (mainly because a crash of your software mean a BSOD ), and you would probably like some more higher level software like Dokan that would help you in that regard.
You need to write a device driver implementing an Installable Filesystem (IFS).
I personally haven't done this but here's a piece of software I know that mounts Linux (ext2/3/4) filesystem on Windows: Ext2IFS.
And here's the SDK from Microsoft: IFS Kit
Take a look at the Subst command. I suggest you invoke it externally instead of simulating what it does, simply because of all the things that can go wrong.
(Side note: The correct term is a volume, not a drive.)
Just as a reference: virtual drives can be created using our Callback File System product, which is a supported, documented and maintained solution.
I'd like to configure visual studio 2005 to copy .dll's based on whether the OS is 64-bit or 32-bit during a build.
I do not want to specify what the platform target is.
My first attempt was to use a batch file to lookup the Windows version, but some 32-bit and 64-bit versions of Windows share the same version number.
Anyone know of any way to check this?
Thanks!
You should be able to read the environment variable %PROCESSOR_ARCHITECTURE%. Here is some great information on it.
http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bitness.aspx
Check out isWow64, I think that shopuld give you what you are after.
Determines whether the specified process is running under WOW64.
Jon's link is a total hack because it relies upon no new processor architectures being added.
See: http://support.microsoft.com/kb/556009 for the "official" batch file method.