I wish to register some of status of my application as a performance object, so that I can monitor its performance by utilising the Windows Performance Monitor.
But I had a problem with Windows 7: the performance object cannot be seen in the list of Performance Monitor, even if my application is running.
My code is exactly the same as the Delphi project in this tutorial:
http://www.wehlou.com/Code/perfmon/index.htm
However, the solution provided in this tutorial doesn't work in Windows 7 either.
Such solution works fine in Windows XP and 2003.
I don't know if there are some changes in Windows 7 which makes my performance object missing.
Please help. Thanks a heap in advance.
Is your Windows 7 computer a 64-bits machine? You may have to provide both a 32 and 64 bits version:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371636(v=vs.85).aspx
The short answer:
Yes you can fix manually the 2 object performance counters (DeltaCount & RawCount) issue under Windows 7 x32. The 2 files generated by PerfMonClient.exe are usable (namely symfile.h and symfile.ini).
Nota: Refer to MSDN for the usage of lodctr.exe.
Prior to that an entry to the registry as follows should created:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PerfMonClient\Performance]
"Open"="PerfData_Open"
"Close"="PerfData_Close"
"Collect"="PerfData_Collect"
"Library"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,00,\
74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,50,\
00,65,00,72,00,66,00,4d,00,6f,00,6e,00,44,00,4c,00,4c,00,2e,00,64,00,6c,00,\
6c,00,00,00
Nota: Library point to %SystemRoot%\System32\PerfMonDLL.dll (location of the performance DLL).
Any attempt to install and/or uninstall them using PerfMonClient.exe App doesn't work even under Windows XP. Forget about that.
Look an feel:
Listing
symfile.h:
#define OBJECT_1 0
#define DEVICE_COUNTER_1 2
#define DEVICE_COUNTER_2 4
symfile.ini:
[info]
drivername=PerfMonClient
symbolfile=symfile.h
[languages]
009=English
[text]
OBJECT_1_009_NAME=PerfMonTest Performance Counters
OBJECT_1_009_HELP=A demo application for your unbridled pleasure
DEVICE_COUNTER_1_009_NAME=RawCount
DEVICE_COUNTER_1_009_HELP=A count of something that goes up and down
DEVICE_COUNTER_2_009_NAME=DeltaCount
DEVICE_COUNTER_2_009_HELP=Something going up all the time, Windows shows difference per time unit
Related
I use TOSVersion.ToString function (uses SysUtils) to detect Windows version. However this is what I get in Windows11:
Windows 10 (Version 10.0, Build 21996, 64-bit Edition)
Is there any reliable way to detect Windows 11? I'm using Delphi 10.3.3.
UPDATE: Windows 11 is officially released and I tried again.
Here is what I get:
Windows 10 (Version 10.0, Build 22000, 64-bit Edition)
As Remy pointed out: using the WinAPI you risk of being in some compatibility mode, resulting in getting a version reported that is lower than the actual.
One alternative is to check the file version of expected files, i.e.
%windir%\system32\ntoskrnl.exe or
%windir%\explorer.exe
using GetFileVersionInfo() and VerQueryValue() - the HiWord(dwFileVersionLS)
should be 22000 or higher (according to Windows NT build/release number).
Another is to look in the Registry under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ at the text values CurrentBuild and CurrentBuildNumber, checking if the highest of both is 22000 or higher.
David already wrote a detailled answer in Checking Windows version on W10 with even more alternatives, although concentrating on the high/low version numbers, not the build. But WMI might help.
(This only works in retrospective with confirmed knowledge.) Check which API exports are available: the idea is that specific functions were introduced with specific Windows releases/versions, so if importing fails for one you know you're on a version below. An outdated example and an outdated list of minimum versions per function will give you an idea. Now you "only" have to find out which new functions are introduced with Windows 11.
Those are all not bulletproof, but you could combine them and then draw conclusions. And after all that you can still try your approach to parse texts instead of relying on numbers only. It also shows how easily you can manipulate your system into reporting different versions as per which method is used.
Official major version number for Windows 11 is 10.
The official build number for the public preview of Windows 11 is
10.0.22000.168
Earlier builds:
10.0.22000.71
10.0.22000.65
10.0.22000.51
Microsoft Windows 11 FAQ
If you want to detect Preview versions, earliest build number was 10.0.22000.51 Windows 11 version history
TOSVersion relies on some hard coded names and logic to return OS name. You will have to implement your own detection, copy and modify TOSVersion record or make wrapper around it, where you can use existing logic for older versions and implement check based on Windows 11 build number to detect Windows 11.
For other general issues and approaches in detecting OS version you can refer to AmigoJack's answer
Except the very weak, atleast for me, solution of considering Windows 10 builds greater than 22000, such as Windows 11, the only solution I found which is actually working is the WMIs Win32_OperatingSystem class - Caption property.
On my dev Win10 machine, it gives the following string: Microsoft Windows 10 Pro.
On my another dev machine, with Win11 installed, the same function gives: Microsoft Windows 11 Pro.
The difference is in string values - "10" vs "11"- but this is at least something far better than the "build greater than" solution.
C# and C++ work well.
The simplest way is to get the version of Kernel32.dll and if Major Version is 10 and Build Version is >= 22000 then you have Windows 11.
See my code here: How can I find the Windows product name in Windows 11?
I come across the following link - https://github.com/felixrieseberg/windows95
Running windows 95 as Electron APP
Is it possible to create any existing application as portable or cross-platform using electron like above?
Can we use Windows 7 or 10 like above without Oracle Virtual Box or VM in an existing Windows 8 machine ?
Need more details on how it is possible to bring an application via electron
Thanks.
If I'm hearing you right, you're wondering if you can put a whole OS into a JS VM running in Electron - and then run your app on top of that.
Please don't do that. Electron is a fantastic cross-platform solution, but my project windows95 was mostly an educational experiment showcasing how powerful modern JavaScript and Electron can be.
This project uses another project called v86, which is capable of virtualising a x86 platform and display its output on a HTML element. Electron is browser-based so that is why this works.
But there are some limitations: It virtualises the x86 platform, which is pretty old by now, and when you have a look at the specification, it says it is at a Pentium-1 state. The demo links on the project's GitHub ReadMe also do not contain any "modern" OS because v86 does not support SSE(2). And since Microsoft requires its users to have a SSE2-compatible CPU* it is not possible to run anything like Windows 7 or newer (Linux may work, anyway).
OSses which support this kind of (deprecated) hardware, may work. As you can see from the "Compatibility" section of the project's ReadMe, some Linux versions and Windows XP "work" but older software, like OS/2, and even newer stuff, like Android, don't (really). So you can't say that everything will work as expected because the execution environment is really limited.
Now to answer your first point, no, I don't think that you can wrap every existing app into an Electron application and run it on new hardware. It may work with old software (which do not require SSE, if you use v86, and that would require a lot of hackery on the v86 side because it is designed to run OSses), but don't quote me on that.
* The section in question reads (at the time of writing) like this:
A Stop error occurs on computers that don't support Streaming Single Instructions Multiple Data (SIMD) Extensions 2 (SSE2).
Upgrade your machines with a processor that supports SSE2 or virtualize those machines.
(emphasis mine, source: https://support.microsoft.com/en-us/help/4088875/windows-7-update-kb4088875)
Back in the days of Delphi 7, remote debugging was mostly ok. You set up a TCP/IP connection, tweaked a few things in the linker and you could (just about) step through code running on another PC whilst keeping your Delphi IDE and its libraries on your development PC.
Today, with Delphi XE2,3,4 you have paserver which, at least at the moment can be flaky and slow. It is essential for iOS (cross platform) development, but here at Applied Relay Testing we often have to debug on embedded PC's that run recent Windows. To do this we have employed a number of strategies but the hardest situation of all is to visit a customer site and wish that one could 'drop in' a Delphi IDE + libraries and roll up ones sleeves to step through and set breakpoints in source code.
It is quite likely - hopefully - that the paserver remote debugging workflow and its incarnations will improve over time but for now I got to wondering how it might be possible to install Delphi + libraries + our source code on a USB key so that with only a minimal, perhaps automated setup, one could plug that key into a PC and be compiling, running and debugging fairly quickly.
I can see that the registry is one of the possible issues however I do remember that Embarcadero once talked about being able to run their apps from a USB key. Knowing how much of a pain it is to install my 20-odd libraries into Delphi though, it is not trivial and needs thinking about.
Has anyone done anything like this or have any ideas of how it might be done?
Delphi does not support what you are asking for. But what you could do is create a virtual machine with your OS, IDE, libraries etc installed in it, then copy the VM onto a USB drive, install the VM software on the customer system, and run your VM as-is. There are plenty of VM systems to choose from.
First, I need to get this out of the way: embedded PCs running Windows?? Sob.
Ok, now for a suggestion: if a full virtual machine isn't an option for this task, application-level virtualization may be. This intercepts registry calls and other application-level information and maps them to a local copy, allowing essentially any application to be turned into a portable version. The good news is that there are free versions of several programs that can turn Windows programs into virtualized apps.
The only one I've personally used is MojoPac, and found it delivered as promised although was very slow running off of a (old, very slow) flash drive.
http://lifehacker.com/309233/make-any-application-portable-with-mojopac-freedom
I haven't used this newer "freedom" version though.
Two other programs I've seen that appear to be popular are Cameyo:
http://www.techsupportalert.com/content/create-your-own-portable-virtual-version-any-windows-program.htm
and P-Apps,
http://dottech.org/26404/create-a-portable-version-of-any-software-with-p-apps/
but I can't vouch for the quality of either of these two.
Hope this helps.
Is it Possible to create bootable (Applications for MBR )application using Delphi or Pascal (I know we cant use vcl , RTL and other stuffs because they depend on OS), but can i use at least Readln and writeln.
If it is true !!! Can we run the program under other OS.
but i know that PE (windows) and ELF (Linux ) formats are different. but at least with some small modification can i do it.
It's worth saying that PE is a very diverse format than ELF.
Not only a few bytes to modify... the whole layout and library access is diverse, and binding is totally diverse.
In order to boot Delphi application in console mode, you can put a small DOS system (take a look at FreeDOS, for instance), then run your Delphi application using for instance DWPL. DWPL allows to run native 32-bit protected mode DOS programs with Delphi 5-7 using the WDOSX DOS extender as the core. I used this in some old hardware with a network adapter, and it worked like a charm. If you are interested in it, I could post some updated code of DWPL.
For such targets, you should take a look at Free Pascal. By nature, you can customize it to whatever target you want. There is even diverse draft Operating Systems written using FPC. See for instance Toro or ClassiOS - the latest uses Delphi executables as source.
You can see the boot code of Toro from here, and a "main program" source code created with it.
But for direct booting applications, booting is not so difficult. The real problem is the hardware layer.
The BIOS gives very little access to it.
Just for the network layer, you'll have to take a look at EtherBoot sites and such to get some low-level network access... but it could be very time consuming to rewrite all those drivers by hand!
In short: all those "pure pascal" OS are only theoretical, running a console and some low-performance network (emulating a poor network adapter like NE2000 or such). So those "pascal" OS are only proof of concept. FAR away from a working solution! But very nice technological challenge, in all cases, very inspiring.
Why reinvent the wheel? If you want a light and fast system, use a custom Linux kernel.
Then use CrossKylix to compile your Delphi application (with no User Interface) into Linux, or even better Free Pascal.
You don't really place "applications" in the MBR.
The entire size of an MBR is 512 bytes, of which you can only use 446 for code.
Good luck creating something useful in that if you don't even have an OS to delegate functionality to yet. Basically all that you can do in the MBR is place code to start a boot loader.
Here's a page with disassembly of an MBR:
http://www.dewassoc.com/kbase/hard_drives/master_boot_record.htm
Why must you write the boot loader?
You could use a ready-made bootloader like GRUB and chainload your PE executable, from it.
Of course, this is very ancient and hairy stuff, but in the good old days, people did this win PE format executables, and a DOS Extender.
For something a little more this-century, why not make your own bootable REACTOS disk, and add your own PE executable written in Delphi to handle the "user shell"?
You could also (but this would require licensing) use the Windows PXE. I think that projects like BartPE probably fall on the gray side of legal, or are at least, unlicensed. Thus, a completely MS-free solution (reactos) for a completely self-contained kiosk PC, with ReactOS, might be more what you are looking for.
Can you write your own operating system? your own UI layer? your own video device drivers? I didn't think so. So use DOS and TurboPascal, or ReactOS and a PE win executable. Or you can use FreePascal and just build your app on a very lightweight portable Linux kernel and root filesystem.
According to a recent blog post by Allen Bauer:
As we’re working on Fulcrum, the next
RAD Studio release with a focus on
cross-compilation for Mac and Linux,
[..]
I figured someone would mention it in the comments, but I thought Mac/Linux support was a few releases further off. Maybe it's just me, but this is huge news.
Does this mean we will see Mac/Linux binaries created with a Delphi release this year?
While I cannot commit to any kind of time frame or release dates, we are working on Mac and Linux targeting. There is also some work going on for 64bit targeting as well, however that will most likely not be in the same time frame as the Mac/Linux targeted releases.
Fulcrum is the code name for the next release, so yes, the next release will include Mac and Linux support. I don't know about the time frame, but "this year" seems reasonable.
Native 64 bit support will be in a future release.
Personally, I prefer this order.
Embarcadero once said that "the release after the next one will support 64-bit". That was supposed to be Delphi 2010. That didn't happen of course - far from it. Not only did it not appear in the release that was indicated, but it now appears it won't be appearing for at least 2 further releases, and in the meantime, things that were NEVER even mentioned have suddenly appeared and been given priority.
So there really is no reason to believe that Fulcrum will happen either, until it has actually been delivered, no matter who talks about it, at least not in the time frame that is being indicated.
Embarcadero have proven less than reliable when it comes to their "roadmap" which is frankly something of a joke - the "current" one still talks about things that have already been delivered as if they have yet to happen, for instance.
FreePascal
I suppose it's not awful news...
If you look at the last road map, you will see Embarcadero is working on Project called "Delphi X"
(source: embarcadero.com)
and according to what Allen said, it seems it's will be compile to Mac OS & Linux at same time, which is great thing.
If Allen said so, it's pretty safe to assume it's true.
The best answer so far is by Michael Rozlog. It is an over hour interview with the Product Manager of RAD Studio and is worth hearing. It covers:
The Delphi Survey
Delphi application showcase
Updates to the Delphi Roadmap
12 Videos of Christmas (later renamed the 12 Holiday videos)
Compiler rewrite
Project Fulcrum: Delphi on Linux and Mac in Beta
Coming soon to more public beta (hopefully)
Delphi Backwards Compatibility
The upgrade cut off policy
Free or low cost versions of Delphi
And a whole lot more.
http://www.delphifeeds.com/go/f/65775?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+delphifeeds+(DelphiFeeds.com)