A foxpro software reads , writes and updates records in a DBF file. I parallely read that same DBF in a c++ application. Will there be any issues if I keep my c++ applications reading DBF file for a long time ?
Yes, the DBF format is multi-user -- nearly every real-world application that uses them is multi-user; we have apps used by hundreds of users for example.
There may be a problem in that your C++ application does not respect the locking mechanism that FoxPro would use, but that's not the same thing. If you use Microsoft Visual FoxPro OLEDB driver properly on the C++ side you won't have an issue, but yes as with anything like this open and close the DBF as quickly as you can.
VFP tables are file based and use shared lock while updating it. If you are doing reading it directly (low level), with only reading there wouldn't be a problem. Since it is data anyway and the best optimised readers are OLEDB\ODBC drivers (ODBC drivers exist for up to version 6. For later versions, Sybase Advantage Server has a driver -local free, remote paid AFAIK but I don't use).
I have been using DBF tables from VFP (yes from VFP) and C# via VFPOLEDB for a long time and I can say I had no issues. Actually, the driver works better from C# vs from within VFP, I don't know why.
Also note that, when you are using VFPOLEDB driver, you are using ANSI mode by default (and shared for read\write unless you change the mode).
If you keep the DBF file open for a long time, you prevent data structure updates to the table. If the VFP application is updated and needs new columns in the DBF file that you are reading, the update would fail until your program stops.
To fix this you or your client would need to change the update process to include your application.
Sometimes VFP applications contain a mechanism that terminates the application. Usually this is some sort of timer that checks a specific field or some file, and then terminates the application. This is often used, because users keep applications open when the leave work. The database is therefore still locked impacting updates and sometimes consistent backups.
You can fix this by implementing the same mechanism in your application.
Related
I'm trying to use QSharedMemory and QClipboard to share data between a SYSTEM process (running on the WinSta0\\Winlogon desktop) and a normal user process, but both fail to share data with others non-SYSTEM processes running on the normal desktop. I belive this is because the WinSta0\\Winlogon desktop is a isolated desktop.
My app is a program that takes shots of the Windows Secure Desktop and send it to clipboard.
The question is: Is there any way to share memory data between that process and non-SYSTEM processes? (Actually I'm using a file to do the job).
On Windows Vista and later, system services run in an isolated session ("session 0"). This is the most likely cause of your problem. (Note that all system services run in session 0, regardless of whether they are running in the SYSTEM security context or not. Similarly, it is possible to launch processes as SYSTEM in an arbitrary session.)
Each session has a separate WinSta0 workstation, and hence a separate clipboard. So clipboard functionality is not going to work here.
It is possible for file mapping objects (shared memory) to work across session boundaries. However, I don't know whether it is possible to do this with Qt. The best bet would appear to be to use setNativeKey which presumably determines the name of the file mapping; to make a file mapping cross session boundaries, use a name that begins with Global\ as described in the MSDN article on CreateFileMapping. If possible, consider using the Win32 API directly rather than Qt.
I'm trying to make a software that backups my entire hard drive.
I've managed to write a code for reading the raw data from hard disk sectors. However, i want to have incremental backups. For that i need to know the changed made to OS settings, file changes, everything.
My question is -
Using FileSystemWatcher and Inotify, will i be able to know every change made to every sector in the hard drive ? (OS settings etc)
I'm coding it in C++ for linux and windows.
(Saw this question on Stackoverflow which gave me some idea)
Inotify is to detect changes while your program is running, I'm guessing that FilySystemWatches is similar.
One way to solve this is to have a checksum on each sector or multiple of sectors, and when making a backup you compare the checksums to the list you have and only backup blocks that have been changed.
The MS Windows FileSystemWatcher mechanism is more limited than Linux's Inotify, but both probably will do what you need. The Linux mechanism provides (optional) notification for file reads, which causes the "access timestamp" to be updated.
However, the weakness from your application's perspective is that all file modifications made from system boot up to your program getting loaded (and unload to shutdown) will not be monitored. Your application might need to look through file modification timestamps of many files to identify changed files, depending on the level of monitoring you are targeting.
Both architectures maintain a timestamp for each file tracking when the file was last accessed. If that being updated is a trigger for a backup notification, the Windows mechanism lacking such notification will cause mismatched behavior on the platforms. Windows' mechanism can also drop notifications due to buffer size limitations. Here is a real gem from the documentation:
Note that a FileSystemWatcher does not raise an Error event when an event is missed or when the buffer size is exceeded, due to dependencies with the Windows operating system. To keep from missing events, follow these guidelines:
Increasing the buffer size with the InternalBufferSize property can prevent missing file system change events.
Avoid watching files with long file names. Consider renaming using shorter names.
Keep your event handling code as short as possible.
At least you can control two out of three of these....
When I used C# i was only able to access user-mode registry accesses.
Is it very difficult to access kernel-mode registry accesses using C++?
I recall reading somewhere I may have to create a dummy windows driver or something?
EDIT: Basically as a hobby project I wish to create a simple registry monitor. However, I do want to catch kernel mode (as well as user mode) registry accesses..... last time I did this, using C# I could not access the kernel mode activity.
There are two ways to achieve this:
Hook the relevant functions in the kernel - the traditional way - which requires a C/Kernel Driver. This is possible on x86 Windows, but on x64 Kernel Patch Protection will detect these modifications and shut down the system (with a bluescreen).
Build a registry filter driver - this is the now encouraged way to attack this problem and is the way process monitor works. You can also build file system filter drivers this way. Essentially, you simply need to pass the information back to userland which boils down to:
IoRegisterDevice(...somewhere in \Devices\YourDriverName...)
IoCreateSymbolicLink(\\DosDevices\Name -> \Devices\YourDriverName)
then a C, C++, C# application should be able to open the file \\.\YourDriverName and DeviceIoControl to it and receive responses.
It is possible to use C++ to write kernel drivers, but see this before you embark on doing so. To be clearer, you need to be really careful about memory in kernel mode (paged, nonpaged) and you're not going to have access to much of the standard library.
As an aside, you should be aware that:
Not all registry hives are accessible to kernel mode drivers, depending on context.
The paths are not common. So the kernel accesses \Registry\System whereas userland accesses HKLM.
G'Day!
I have an executable (Unix or Windows - it should be cross-compiling). If one opens this executable by any editor and write some stuff to the end - the application would still run perfect.
On execution, the application with all its data loads to the RAM. So, the user-written part of file is also loaded into memory.
Is there any chance to read this data?
I need this data in fast access. Other workarounds are not OK, because it takes too much time:
Reading directly from file (on hard disk) or mapping it is not fine, because the application have to read this file on each run, but this application has lots of launches per sec.
Using shared memory with another process (something like server, which holds data) is not cross-compiling
Using pipes between app and so-called server is not fast enough, imho.
That's why I decided to write some stuff to the end of application.
Thanks in advance!
Are you re-inventing
exe packers (see http://en.wikipedia.org/wiki/Executable_compression)
embedded resources? A portable approach was described here Is there any standard way of embedding resources into Linux executable image?
I also think you're might be optimizing the wrong things.
Reading directly from file (on hard disk) or mapping it is not fine, because the application have to read this file on each run, but this application has lots of launches per sec.
The kernel[1] is way smarter than we are and is perfectly capable of caching the mapped stuff. Heck, if you map it READ-ONLY there will be no difference with directly accessing data from your program's base image.
[1]: this goes for both WIndows and Unix
i need to add some files to results returned by FindFirstFile and FindNextFile under windows. Is this possible by file system filter driver or what type of drivers?
Thank you
You can do this by File System Filter Driver. But you can do this by implementing a system wide API hook. I have not tried it before but you really don't need to take the pains of writing the drivers and making the system unstable in case of spoiling the driver stack.
System Wide API Hooking
API Hooking Revealed
As pointed out you can use a file system filter driver (legacy or mini-filter, based on fltmgr). However, I would strongly recommend against the system-wide API hooking. Simple reason: if you do it in usermode it's not really going to be system-wide and if you use an SSDT-hook or some hotpatching method you risk the system's stability. An alternative, albeit equally shady as system-wide hooking, would be entry-point stealing. In this case you use the device object of the volume (in which you're interested, just listen for the attach notifications or enumerate them at startup) to find the driver responsible for it and modify the major function entry points in the driver object (Ilho pointed you into the right direction already).
A file system filter driver is the supported method to do just that.
In the latest Windows 7 WDK the sample under 7600.16385.1\src\filesys\miniFilter\minispy provides a good starting point. Biggest problem with mini filters for a private person is to get assigned an altitude for the driver to load at. Because using just any altitude can well lead to BSODs - and in case of FSFDs you might even risk your data integrity (although the kernel steps in with the BSOD to prevent that). You only need to fake IRP_MN_QUERY_DIRECTORY - this is the minor control code you're looking for when you are handling the IRP_MJ_DIRECTORY_CONTROL major control code. All others you can pass through as long as you don't need to allow the file to be opened, read or written and such. How to do that can be seen in the 7600.16385.1\src\filesys\miniFilter\passThrough sample source.