I have a VB6 application that uses FileNet Visual Workflo (on FileNet Image Services) for the workflow engine. All of our application code has been updated to work correctly on both Windows XP and Windows 7, but there is a performance problem on Win 7 when attempting to get work object information from FileNet.
Within the application are calls such as
ErrorCode = APIVWAPI.VW_GetString(wobjid, lvFldName(idx - 1), aStr)
to which I've isolated the performance issue.
APIVWAPI is defined via late binding as follows:
Set APIVWAPI = CreateObject("VWApi.Srv")
The
ErrorCode = APIVWAPI.VW_GetString(wobjid, lvFldName(idx - 1), aStr)
line takes approximately 40 times longer on the Windows 7 machine (Core i7 3.4GHz CPU 8GB RAM) as it does on a Windows XP machine (Pentinum 4 3.2GHz, 1GB RAM). This line (and those like it) is called multiple times when retrieving queue items. As an example, a 120 item queue will take about 40 seconds to load on Windows 7 and <1 second on Windows XP.
Both systems are using the latest FileNet IDM components (4.0.3 fix pack 1). The Windows 7 environment is 64-bit Enterprise. XP is 32-bit Professional. The FileNet Visual Workflo components are the last, version 3.6.
Does anybody have any experience with FileNet IDM on Windows 7, and/or dealing with performance problems that appear to be DLL related on Windows 7 - and suggestions?
It turns out that the performance issue was related to drawing a ListView on the screen. Making the ListView not visible while retrieving the data, and then drawing the ListView once all data was retrieved, greatly increased performance.
I'll chalk this up to differences between 32-bit and 64-bit systems.
Related
I run the same application on Windows 10 and Windows 7 (both 64-bit) and used Process Explorer to monitor the Virtual Size. I noticed that the Virtual Size of the application running on Windows 10 is much larger than running on Windows 7.
By using VMMap, in Private Data:
Windows 10 - 1 address with 4.2GB is reserved and not committed.
Windows 7 - 2 address with 15MB are reserved and not committed.
So my questions are:
Why there is a large memory has been reserved? Is it just a different memory management done by Win10 and Win7?
Or, there is something to do with the application that I ran? (The application has no problem to run on Win10 & Win7)
Is there any suitable indicator to track memory leak? (Eg: 'Committed' value in VMMap) It seems like so much discussion/argument on this :P
I am a developer, and I'm responsible to maintain 3 different systems, one is programmed with jdev 11g and ADF, another with forms 6i and another with forms 10g .
The problem is that when I barely make the windows 10 64-bit machine work the 6i with the 10g the Jdev stops walking, or its weblogic goes crazy, when I correct the errors in jdev one of the two forms or both stop working. I have reinstalled and reinstalled everything several times, I have been doing this for a week and a half and I do not get the formula, Has anyone had a similar experience? Is there hope that these tools coexist or is it better I use separate virtual machines?
I have an XP SP3 virtual machine with 4GB of RAM in a server, where I have both forms but it is very slow.
What do you advise me to do?
From my point of view, I'd suggest having 3 separate virtual machines, one for each development tool. Operating system version and Oracle software version should match (i.e. Oracle tool should have been certified on Windows version you put onto the virtual machine). Forms 6i is really ancient, but many people still use it (we have it too), so you can't really expect to make it work properly on a brand new Windows 10. I've read that there are "hacks" that make it possible - I prefer porting my virtual machine to a new computer when necessary, without having to install and configure everything from scratch.
As you wouldn't be running all 3 virtual machines at the same time (would you?), it doesn't matter whether computer you install them on is very powerful or not. For example, my PC has 8GB RAM. I designated 1GB to my Developer 10g virtual machine (along with 10GB disk size), put Windows XP SP3 onto it and everything works just fine. When I had PC with 4GB RAM, I used 512MB RAM on virtual machine - no problem either.
There's no need to run virtual machines on the server (if it is slow), if your own PC is a better choice.
Although it is possible to run multiple Oracle software products on the same computer (you'd install each of them into its own Oracle Home (i.e. directory)), problem arises when they seem to collide (as you described it - you make one of them work, which causes another two to fail).
Therefore, yes - it is an opinion-based answer, but I'd suggest 3 virtual machines.
I currently have a 32-bit PowerBuilder application that we are trying to port over to a Windows 7 64-bit environment. Realizing the obvious that PowerBuilder 10.5 was built previously before Window7 came out and the big also the obvious fact that this application was built within a Windows XP 32-bit environment.
The 32-bit PowerBuilder application spits out the following error message when deployed on a Windows 7 64-bit machine.
Application Terminated. Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow
The database profile setup points to an OLEDB and the backend database is MSSQL 2008. Currently the application does run on the Windows7 64-bit environment and seems to be working in an inquiry mode only. Meaning we can read some of the records on the datawindow, but as soon as you try to make a transaction it blows up.
My question is - Is it possible to get a 32-bit app working in a 64-bit environment?
So far the client is asking to come up with possible solutions without the idea of upgrading to PowerBuilder 12.5. Essentially they want to stay at 10.5 but yet get the app working from a 32-bit environment to a 64-bit...apples to oranges if you know what I mean. Further investigation is needed into whether the code will not function in 64bit or dll issues with powerbuilder client runtime in 64bit. They are really trying to stay away from any app rewrite since the application is older than when Christ was a carpenter. The app was originally built in PB 6.5 I think.
So far I have the following ideas but I am new to this:
- I understand that Windows 7 comes with a virtual machine IIRC. I think it's called WOW64. Is it possible to create a virtual on a server and have the users run a 32-bit application inside a 64-bit machine? Then create a shortcut of somekind for the user to simply click on?
We do have a virtual XP machine and a virtual Windows7 64 bit machine for testing. PowerBuilder 10.5 actually installed on Windows 7 and seems to be working fine. However running the application in run mode or debug causes many errors as you can imagine.
The application has been built in XP and run on Windows 7, but the results yeild the above error message.
I have not looked yet into the Run under Compatibility mode, but I am told by the team it will not work.
I have not looked at UAC or ALC User management yet. Could that be something affecting the 64-bit system?
I know this is app unrelated but...I have seen in some cases 32-bit applications work in a windows 64-bit environment by simply targeting certain DLL files. An example case is Microsoft Flight Simulator X where the 32-bit game would crash in windows 7 64-bit. The solution for that was to simply go get a Vista 64-bit DLL file called uiautomationcore.dll and copy that into the windows environment. The Games also have to be installed on the root of C: in order to work.
Does anyone have any recommendations on how I can approach this problem?
I apologize If I'm vague in my notes here.
UPDATE: Has anyone had any experience with PB 10.5 runtime files on a 64 bit machine? I am wondering if the powerbuilder client runtime is installing its dlls into the correct location of the application C:\XXX or can't find it? Wondering how to approach this.
Basically nothing should prevent a 10.5 PB app to run on Win7/64. I develop and run several products in PB11.5 (also a 32bit IDE) on a win7/64. And btw, some older PB like 9 still run on Win7, so is likely PB6.5. The problem must be elsewhere, relative to the app design.
WoW64 (and Wow6432Node in the registry) is not a true VM, it's a bunch of services and system API hooked with fallbacks for 32 bit applications (and legacy applications that do not conform to the novelties introduced since Vista)
Error: Invalid DataWindow row/column specified at line 44 in function ivvisiblecolumn of object objectwindow sounds typically like an incorrectly handled return value (where a computed row number is getting negative or null before trying to access a property or data at that given invalid row), or it could be relative to the way to get back an autoincrement value from the db after an insert
beware of the UAC management that could lead to unexpected behavior with legacy application, especially if the application is using a database: the UAC guidelines tells not to install data managed by the application in the Program Files folder that is now Read only (since Vista - that guideline is since XP). Instead you must put that into a ProgramData sub-directory if it is accessible by everyone and into a user local AppData if the data is just for the current user. Win7/Vista can silently conforms to the standard by duplicating the data locally to the user (in the Users\username\AppData\Local\VirtualStore) while still pretending to the application that it is currently accessing it from Program Files...
you could give a try with Dependency Walker to look for the incorrect dll problems
We moved many of our applications to Windows 7 64bit. The only issue we ran into was with the database connections. You are running a 32bit application so you need to connect to 32bit database. If you bring up "Data Sources (ODBC)" from the control panel, you will be looking at the 64 bit entries. You need to use the 32 bit ODBC found in "C:\Windows\SysWOW64\odbcad32.exe". The Registry entries you need are in the following locations...
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
or
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBCINST.INI\ODBC Drivers
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
HKEY_CURRENT_USER\SOFTWARE\Wow6432Node\ODBC\ODBC.INI\ODBC Data Sources
I've always wanted a minimal windows NT build . Sounds like one's already there : MinWin. Can anyone tell me the exact design or architecture of MinWin and is it used in Windows 7 ? Windows Server 2008 already has a minimal Core build available for deployment . Why not Windows 7?
Windows Server 2008 R2 also has the same core build available for it.
Windows 7 is a client OS and it's highly unlikely that anyone would ever want to use a "core system" version of it. For instance the core server SKU doesn't have the ability to use any video cards beyond the basic VGA driver or have a shell - the only UI is cmd.exe. There's no .Net framework, no multimedia, etc. As I understand it from what I've seen on the web, Minwin has even less functionality than core server does - from what I've seen, it doesn't even support graphics.
Obviously, that's 64-bit windows.
Also, what's the maximum amount of memory a single 64-bit process can use?
I was kind of counting on using it all...
(Yes, I know what I'm doing, please don't tell me that if I need that much RAM i must be doing something wrong)
Also, is this the same for a .Net 2.0 process? Or is there a lower limit for .Net?
What version of windows? it differs from XP to vista and from home to business versions of vista, and I would guess again for server.
see here for more info on maximum ram for diffrent windows versions
for Windows Server 2008 Datacenter MS quote 2 TB of physical memory.
Link
From http://technet.microsoft.com/en-us/library/cc758523.aspx
- Windows Server 2003, 64 bit Datacenter Edition supports physical memory up to 512GB
A single process should be able to use most of it, some will be used by the OS.
The answer from Re0sless is better then mine. The limit is now 2TB, in Datacenter SP2, and 2008.
We run Windows boxes with 16 gigs of memory, but that is because we are running multiple VM Ware instances, I presume you mean in a single instance. On Vista it depends upon the edition. It breaks out like this:
Vista Basic: 8 GB
Vista Home Premium: 16 GB
Vista Business/Enterprise/Ultimate: 128+ GB
Something we found out recently: with MySQL running on Win32, you can only use up to 2GB per process. On Win64, the memory is not managed as well and a single MySQL instance will run your memory into the ground. Ours used up all 16GB we have. So regarding how much memory 1 64-bit process can use: the answer is however much the OS allows.
According to wikipedia you can have 128 GB of physical RAM in a 64-bit Windows XP computer.
This is a Windows Server machine.
As for which edition (Datacenter, Enterprise, etc)... Whatever it takes to give my little .Net Process as much memory as it can.
Switch to Linux. You will not have any of these issues and you will get better performance.