Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

API WIN32 PROBLEM


2 replies to this topic

TLA

TLA
  • Members
  • 26 posts

Posted 05 October 2001 - 16:27

Hi All,

I have encountered a tremendous problem with the use of Api win32 on my ISScript.

I build a function which redirect input and output result of a process launched via CreateProcess.
So I translate the MSDN article (Q190351) In Isscript.
In this code the function CreateThread is requiered with the following prototype
HANDLE
WINAPI
CreateThread(
   LPSECURITY_ATTRIBUTES lpThreadAttributes,
   DWORD dwStackSize,
   LPTHREAD_START_ROUTINE lpStartAddress,
   LPVOID lpParameter,
   DWORD dwCreationFlags,
   LPDWORD lpThreadId
   );

Example of use in MSDN
     hThread = CreateThread(NULL,0,GetAndSendInputThread,
                             (LPVOID)lpvThreadParam
,0,&ThreadId);

My problem is about the GetAndSendInputThread parameter which refers  to function address with the following declaration :
DWORD WINAPI GetAndSendInputThread(LPVOID lpvThreadParam);

and with the following implementation
DWORD WINAPI GetAndSendInputThread(LPVOID lpvThreadParam)
  {
     ....
     HANDLE hPipeWrite = (HANDLE)lpvThreadParam;
  .....
}

How can I translate this is IScript???

Thx



Robert Graham

Robert Graham
  • Members
  • 70 posts

Posted 06 October 2001 - 05:30

Hi!

I really do not think you will be able to implement this technique directly in ISScript.  ISScript does not provide any type casting support that I am aware of.

This problem is rather simple to solve - implement functions in a C++ DLL called by IS rather than in ISScript.

However, I would suggest you reconsider your design first.  I am not sure what you need to accomplish, but there is always an alternative.

Irrespective of what your objective is, I think it is very questionable as to whether you can implement this sort of code in conjunction with IS.  Any process that creates and uses multiple threads requires a high degree of control and careful synchronization, even for the most simple of tasks.  You have little control at best, and more realistically, effectively  no control over IS.  It runs more or less on it's own sequence of activities, and only allows the developer to intervene and act when it raises an event.  In between events, you cannot alter the course of execution.  Not a very likely candidate for the cooperative nature of multithreading.

I also question whether the IS runtime is even marginally threadsafe, much less to anywhere near an adequate level to try to create threads from within an IS process.   I think this approach could be a lot of effort maybe only to discover the process was too unstable to be viable.

If you really need this capability, you probably would want to consider managing the process from a standalone parent executable that is either launched by IS at the end of it's cycle, or launched with LaunchAppAnd Wait with IS being suspended while your parent process executes.  IS is just not a good candidate for being the actual parent itself.

Again, I do not know what you are trying to do, but I would examine why there is a need to redirect a console process in the first place.  Nowadays console processes tends to lie at one extreme or the other - nearly totally automatic or nearly totally manual.  (at least in the context of doing a software installation.)  Either you run a batch file, or you run single commands at a time from the C prompt.  Not much in between.   This approach implies a higher level of interactivity.   You can possibly achieve the same ends by a different strategy.  

My setups build and populate very large , complex SQL Server databases, among other things.  The process is very site specific as well.  It is a console process from start to finish.  

We used to have to build the databases manually, and it was too complex for the clients.  It took a lot of work to automate that process, but it was a lot of work to have to get on a plane and fly somewhere everytime there was a problem or an installation to be done.  

Now the database build runs itself.  I have some custom dialogs in my IS script that prompt the user for the various input needed, and then there are pages and pages of code that set everything up and write out batch files to execute the build.  It was a major effort to perfect the process, but now it is very stable - not had an installation fail on the database build yet.  And instead of having to go do an install, we just burn a CD and send it out.  (Before we ourselves had problems with the manual procedure, and sometimes did not get it right on the first try).  Now even the clients install it with no problems!

It may require a lot of code, but there is probably nothing you get from redirection that could not be accomplished by strategic use of batch files, etc.
This redirection business is no minor effort either, and it may not be very stable.

Good Luck!