Win16 Apps loose time sync (WOWEXEC.EXE BUG?)
The Problem:
ASKER
Mujeeb,
Thank you for the VDM Timer Tick Article. I too saw that article before posting this question. You are correct that it is the cause of the problem, however your solution was #2 in the unacceptable answers list. I feel there has to be some API call somewhere I can use to force NTVDM / WOWEXEC to update the time, something that is called on every Win16 application startup.
Thank you for the VDM Timer Tick Article. I too saw that article before posting this question. You are correct that it is the cause of the problem, however your solution was #2 in the unacceptable answers list. I feel there has to be some API call somewhere I can use to force NTVDM / WOWEXEC to update the time, something that is called on every Win16 application startup.
Hi :)
The call that u are reffering or searching cannot be in a 16 bit appication. This i think is done when wow set's up the environment for the new 16 bit application and as the article says that every time when ever a new application is loaded the common BiosDataArea tick count is initialized to the current system time. So each running application see the new and correct system time even if they have changed it.
Let say even if u do find a call, it will be useless, and why is that because once your appication is started it do not see any more the system time it starts seeing the time from within the wow. So even knowing the call will not help and i think whatever call it might be it is 32 bit and will be useless in 16 bit application.
The solution could be that if u find out that where is that BiosDataArea where it keeps the time tick. Then write an 32 bit application which reads the current system time and keeps updating that area. Which i think NT will not allow because of separate memory area.
Or better solution would be that write two set of applications which can be running all the time. One is 32 bit which reads the current time and puts it either in registry or some ini file and the other part of the application which is 16 bit reads the correct time from this registry entry or from the ini file and keep synchronising the time with the machine time.
If u can modify your orignal applications then write a small sub which reads the time from the designated place which is updated by the 32bit application. This way u can run all your application in separate wow if u want and can still have the current time in each of them.
The call that u are reffering or searching cannot be in a 16 bit appication. This i think is done when wow set's up the environment for the new 16 bit application and as the article says that every time when ever a new application is loaded the common BiosDataArea tick count is initialized to the current system time. So each running application see the new and correct system time even if they have changed it.
Let say even if u do find a call, it will be useless, and why is that because once your appication is started it do not see any more the system time it starts seeing the time from within the wow. So even knowing the call will not help and i think whatever call it might be it is 32 bit and will be useless in 16 bit application.
The solution could be that if u find out that where is that BiosDataArea where it keeps the time tick. Then write an 32 bit application which reads the current system time and keeps updating that area. Which i think NT will not allow because of separate memory area.
Or better solution would be that write two set of applications which can be running all the time. One is 32 bit which reads the current time and puts it either in registry or some ini file and the other part of the application which is 16 bit reads the correct time from this registry entry or from the ini file and keep synchronising the time with the machine time.
If u can modify your orignal applications then write a small sub which reads the time from the designated place which is updated by the 32bit application. This way u can run all your application in separate wow if u want and can still have the current time in each of them.
ASKER
Text above?
Hi :)
I think u are not getting it. The way 16 bit application works is clearly explained in the article and this is a limitation from the OS and can only be fixed from OS only.
As i said earlier that BiosDataArea is only set by NTVDM/WOW which are 32 bit applications, and 16 bit application cannot see the direct clock they only see the BioaDataArea set by the OS.
Anyway i told u the hard reality and u are closing your eyes from this. Just remember that i am the first one to told u so :)
I think u are not getting it. The way 16 bit application works is clearly explained in the article and this is a limitation from the OS and can only be fixed from OS only.
As i said earlier that BiosDataArea is only set by NTVDM/WOW which are 32 bit applications, and 16 bit application cannot see the direct clock they only see the BioaDataArea set by the OS.
Anyway i told u the hard reality and u are closing your eyes from this. Just remember that i am the first one to told u so :)
Hi :)
U said that u are looking for some kind of stimuls to ntvdm so that it syn the time. So the only way that u can stimulate the ntvdm/wow to syn the time is that u spawn under application from your program which will make ntvdm to syn the time when it will set the environment for the application.
The application which u spawn can just exit as soon as it loads. So this will stimulate the ntvdm to syn the time with operating system.
One thing i will remind u that 16 bit application do not know that they are running in 32bit environment and their is no way that u can call a 32 bit call. Hope u get this :)
U said that u are looking for some kind of stimuls to ntvdm so that it syn the time. So the only way that u can stimulate the ntvdm/wow to syn the time is that u spawn under application from your program which will make ntvdm to syn the time when it will set the environment for the application.
The application which u spawn can just exit as soon as it loads. So this will stimulate the ntvdm to syn the time with operating system.
One thing i will remind u that 16 bit application do not know that they are running in 32bit environment and their is no way that u can call a 32 bit call. Hope u get this :)
ASKER
Yes I do FULLY Understand what you are saying. I'm intimately familiar with the DOS loading process and the DOS BIOS area of memory. I know how NTVDVM emulates it for 16 bit apps, and I'm even aware of the fact that the behavior I'm seeing is designed into the Operating System. What I believe you have missed is that your proposed solution is not a solution that I can live with. I wish I could go into the fine details with you but I can not. This is a military application and is governed by powers well above my head. Writing a second or third application to force the desired behavior is TOTALLY unacceptable. So I think what you have told me is that preferred answers #1 and #3 are not possible. I am still looking for preferred answer #2. I saw you used a util to list the imported and exported API calls of VTVM. Thanks, I'm using that list to try and solve my own problem. If anyone knows what 16 bit API call I can make to resync the clocks please answer.
Hi :)
Their is no other solution. Because even if u make an 16 bit call for the time it will be handled by the ntvdm and iti will return u the time from the BiosDataArea.
The setting of the time is done by reading the real clock which is done through a 32 bit call using the call routines in the kernel32.dll and these calls are only made by ntvdm. Their is no call which can bypass ntvdm because for 16 bit application it is like they are running on a dedicated pc with windows 3.11 and have no awareness of any 32 bit shell.
Also all the exported calls in ntvdm are 32 bit so their is no way u can utilise them.
Why i am keep answering u is that instead of waisting time for something which is not possible why not make use of the way which is available. for example as i told u before that u can have one 32bit application which reads the current time from system and keep writing to one file the current date and time and your application can read that file and take the date and time from the file and initialises their time.
Or u can from time to time execute another application which just quits after loading but during this loading process ntvdm will initailise the time for u.
The only one who initialises the time is ntvdm only and it is a 32bit application and as i said to u before that 16bit application has no idea of the 32bit shell and u cannot call 32bit api and infact their are no 16bit api call in ntvdm.
All the calls for the windows fuctions for 16bit applications are from kerne386.exe and user.exe to simulate 16 bit windows.
Their is no other solution. Because even if u make an 16 bit call for the time it will be handled by the ntvdm and iti will return u the time from the BiosDataArea.
The setting of the time is done by reading the real clock which is done through a 32 bit call using the call routines in the kernel32.dll and these calls are only made by ntvdm. Their is no call which can bypass ntvdm because for 16 bit application it is like they are running on a dedicated pc with windows 3.11 and have no awareness of any 32 bit shell.
Also all the exported calls in ntvdm are 32 bit so their is no way u can utilise them.
Why i am keep answering u is that instead of waisting time for something which is not possible why not make use of the way which is available. for example as i told u before that u can have one 32bit application which reads the current time from system and keep writing to one file the current date and time and your application can read that file and take the date and time from the file and initialises their time.
Or u can from time to time execute another application which just quits after loading but during this loading process ntvdm will initailise the time for u.
The only one who initialises the time is ntvdm only and it is a 32bit application and as i said to u before that 16bit application has no idea of the 32bit shell and u cannot call 32bit api and infact their are no 16bit api call in ntvdm.
All the calls for the windows fuctions for 16bit applications are from kerne386.exe and user.exe to simulate 16 bit windows.
ASKER
There must be something wrong with my browser. It doesn't she me the latest answer, only says Text above....
ASKER
Yes I knoe the shelling will update the time. I already ahd the application written and tested. Like I'm telling you NO THATS NOT AN ACCEPTABLE ANSWER, my customers are telling me they are not going to use that method. Now if it turns out that there is no way (I'm not totally convenced yet) then fine you can have the damn points. But again that is not an answer I can live with. So please let someone else take a shot at it ok?
Hi :)
U can give points away to anyone u like, i am not here for the points. The only reason i am here is to help out as much as i can. U can surely give away the points to anyone u like even if i am the right person who answered u.
If your customers do not like the solution, than u must force your customers to let u move to the 32 bit VB code. Yes yes i know u already said that u cannot move to 32bit VB.
Anyway i will also search and if i come up which i doubt that their is any otherway, i will let u know.
I also know that it is not the answer u like to have. But it is a fact that u cannot call 32bit calls from an 16bit application. Also u cannot call any function in ntvdm though it is the shell under which the application runs. The reason as i stated before and stateting again that 16bit application do not know that their is something like 32bit world.
In principle your requirement is wrong itself.
U can give points away to anyone u like, i am not here for the points. The only reason i am here is to help out as much as i can. U can surely give away the points to anyone u like even if i am the right person who answered u.
If your customers do not like the solution, than u must force your customers to let u move to the 32 bit VB code. Yes yes i know u already said that u cannot move to 32bit VB.
Anyway i will also search and if i come up which i doubt that their is any otherway, i will let u know.
I also know that it is not the answer u like to have. But it is a fact that u cannot call 32bit calls from an 16bit application. Also u cannot call any function in ntvdm though it is the shell under which the application runs. The reason as i stated before and stateting again that 16bit application do not know that their is something like 32bit world.
In principle your requirement is wrong itself.
Hi :)
Hi their, i tried looking every where their is no solution for the problem except that u do some sort of shelling.
Reason as i said to u before. 16 bit do not know that their is 32 bit world and u cannot make 16 application call 32 bit function becuase the way the code is align with the address space.
U better ask the customer to either let u go and convert the application in 32 bit or be satisifed with the shelling if it does the job. Have u checked my comments in other question u posted in VB programing.
Hi their, i tried looking every where their is no solution for the problem except that u do some sort of shelling.
Reason as i said to u before. 16 bit do not know that their is 32 bit world and u cannot make 16 application call 32 bit function becuase the way the code is align with the address space.
U better ask the customer to either let u go and convert the application in 32 bit or be satisifed with the shelling if it does the job. Have u checked my comments in other question u posted in VB programing.
ASKER
Mujeeb,
Thanks for the attempts to help out. Write an answer to this question and I'll give you the points for the effort. Seems there is no acceptable answer to the question.
I'm sorry if I came down on you hard for answering the question. I was only upset because this site will not allow more than one person to answer a question at a time. While it seems that you were correct, there are no other options, I kept hearing the same answer over and over that I had to keep rejecting to allow someone else a chance to answer. No offence intended I just wanted a second opinion.
Roy
Thanks for the attempts to help out. Write an answer to this question and I'll give you the points for the effort. Seems there is no acceptable answer to the question.
I'm sorry if I came down on you hard for answering the question. I was only upset because this site will not allow more than one person to answer a question at a time. While it seems that you were correct, there are no other options, I kept hearing the same answer over and over that I had to keep rejecting to allow someone else a chance to answer. No offence intended I just wanted a second opinion.
Roy
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I did write the shell applicatoin before I asked the question and it worked. It was rejected by my customers. They pay my salery, therefore, if they want to pay me to look for the impossible, thats what I do. Have a good one.
This is info from Article ID: Q102611
Windows NT virtual DOS machines (VDMs) keep their own system time. Each time an MS-DOS-based application or a 16-bit Windows-based application is started, its BiosDataArea tick count is initialized to the current system time. When an MS-DOS-based application sets the time in a VDM, it is reflected in that VDM only. When a 16-bit Windows-based application changes the time, the new time is reflected in all 16-bit Windows-based applications running in Windows on Windows (WOW).
With this info the only way to have your application have their time set properly is that u run all your application in one VDM.
Your dummy program is the only way to have this problem fixed as it seem in the above inforation context and it is not a dirty way it is the only way.