Why, why why... everytime I move to a new pc tclapp fails to work??
Georgios Petasis
difficult every time I re-install my os or move to a new computer :-(
(I have posted again the same issue 2 years ago...)
The situation:
OS: Vista 64-bit.
Tcl: 8.4.14 32-bit.
TDK: 3.2.
I run tclapp from the command line (by running a Tcl script). The first
time I ran my script, it worked. The second time I ran it, it didn't
(its the same script!!!). After that, the script has failed to run :-(
What I do in the script, is the following:
It copies the files I need into a specific directory.
It runs tclapp to wrap the app. The call to tclapp is the following:
eval exec [list $TclApp] -- -relativeto [list $OutputDir] $Files\
-pkg Itcl -pkg img::png -pkg BWidget \
-pkg Itk -pkg Iwidgets -pkg tcom -pkg tile \
-pkg struct::tree -pkg struct::list -pkg cmdline \
-prefix [list $prefix_exe] -icon [list $icon] \
-out [list $output_exe] \
-encoding cp1251 -encoding iso8859-1 -encoding iso8859-7 \
-encoding utf-8
which when runs, corresponds to the following:
{C:\Program Files (x86)/TclDevKit/bin/tclapp.exe} -- -relativeto
C:/Users/petasis/Editor-Runtime <Files_with_absolute_paths> -pkg Itcl
-pkg img::png -pkg BWidget -pkg Itk -pkg Iwidgets -pkg tcom -pkg tile
-pkg struct::tree -pkg struct::list -pkg cmdline -prefix {C:\Program
Files (x86)/Tcl/bin/base-tk-thread-win32-ix86.exe} -icon
C:/Users/petasis/Editor/win/AppIcon.ico -out
C:/Users/petasis/Editor/win/BowTieBuilder-231.exe -encoding cp1251
-encoding iso8859-1 -encoding iso8859-7 -encoding utf-8
The error I get is:
error package 'Itcl' is not known
If I use the -compile option, then the package tbcload is not found.
The graphical tclapp seems to work though, if I use the preferences and
add the paths to the tcl library.
I have also defined the TCLAPP_PKGPATH environmental variable, with the
value "C:\Progra~2\Tcl\lib;C:\Progra~2\Tcl\lib\tcl8.4". I have also
tried the value "C:\Progra~2\Tcl\lib C:\Progra~2\Tcl\lib\tcl8.4" without
any improvement.
What should I define to make tclapp work?
I really think that the next version should definetely have an option to
specify the package search directories! (No, -pkgdir does not do that :-))
George
Georgios Petasis
After many hours of various experiments, I realised that the environment
when running tclapp (and this is windows explorer!) was not updated with
the new environmental variable (TCLAPP_PKGPATH).
Under my brand new vista 64-bit, If I opened a dos prompt, the variable
was there. But double-clicking a tcl script from explorer was running
without the variable!
A simple reboot solved the problem. But I still want this to be a
command line option in tclapp. I have lost many many hours in setting
this variable to a proper value and making tclapp work!
George
O/H Georgios Petasis έγραψε:
Arjen Markus
> Because Vista environmental variable handling is awful?
> After many hours of various experiments, I realised that the environment
> when running tclapp (and this is windows explorer!) was not updated with
> the new environmental variable (TCLAPP_PKGPATH).
>
> Under my brand new vista 64-bit, If I opened a dos prompt, the variable
> was there. But double-clicking a tcl script from explorer was running
> without the variable!
>
> A simple reboot solved the problem. But I still want this to be a
> command line option in tclapp. I have lost many many hours in setting
> this variable to a proper value and making tclapp work!
>
This sounds like a problem that will be almost universal!
(At least for any program that wants to use its own environment
variables ...)
Something to watch out for.
Regards,
Arjen
Ralf Fassel
| A simple reboot solved the problem.
I would expect that restarting the explorer (i.e. logout/login) would
also make the new environment variable known (I'm not 100% sure).
Since you install as admin and then change to ordinary user (you do,
don't you?), this would be a minor problem then...
As an alternative, you could associate the TCL files with a wrapper
script which sets the variables prior to invoking the .exe. However,
this would require the script to be changed when the installation
location is changed...
R'
MartinLemburg@UGS
this described problem is really a universal problem, but could be
solved in different OS', but not in MS Windows OS', not in 2000, XP
and like George told not in Vista.
The problem is really simple:
1. the user sets an environment variable in its control panel/system
dialog
2. all running process work on their own COPIES of the environment, so
they don't know about this new environment variable
3. starting a new process (explorer, command line, tcl shell, etc.)
will allow to access this new environment variable, because the
environment was changed in the mother of all processes, so that every
new process will own a copy of the changed environment
4. starting a new explorer is not that easy, because first all
explorer processes must be closed down. If not this exporer will start
as a kind of sub process of the first started explorer.
Another version of the problem:
1. a developer builds an executable with function, that sets an
environment variable and uses a function from a loaded DLL. The
developer things of a very simple kind of IPC.
2. the developer assumes, that this DLL will know about this new or
changed environment variable, but this scheme will fail, because (on
Windows) a DLL has is own copy of the environment, like a kind of sub
process.
...
I hoped stepping from W2k to XP, that MS could have implemented a kind
of push or pull system for the case of a changing environment - "push"
means, update the "main" processes environments, while "pull" means,
that the processes gets a signal, that the environment changed and has
to be updated.
But this hope didn't full fill even with Vista, sad!
Bye and best regards,
Martin Lemburg
UGS - Transforming the Process of Innovation
Donal K. Fellows
> I hoped stepping from W2k to XP, that MS could have implemented a kind
> of push or pull system for the case of a changing environment
I thought there was something you could listen to for notifications
about this (is there a way to listen for registry updates?) but hardly
anything does. I also bet that even if you get such a message, you've
still got to perform all the substitutions yourself too.
> But this hope didn't full fill even with Vista, sad!
I think Explorer listens for this sort of thing (since all desktop
shells are children of an explorer instance, and starting a new shell
leads to variables being visible) so it must be possible. No idea how
though.
Donal.
Alexandre Ferrieux
wrote:
> Martin Lemburg wrote:
> > I hoped stepping from W2k to XP, that MS could have implemented a kind
> > of push or pull system for the case of a changing environment
>
> shells are children of an explorer instance, and starting a new shell
> leads to variables being visible) so it must be possible. No idea how
> though.
A less sexy explanation is that Explorer owns the GUI which you use to
set the environment variables; so it doesn't have to be "notified" ;-)
To check this, try modifying directly the file/registry/whatever which
store the environment variables, and see if (1) new children notice
and (2) Explorer notices. If it does, a ProcMon hook onto Explorer
should reveal the filesystem API it uses (polling on the file's
date ?)...
-Alex
Georgios Petasis
at least for explorer! I suspect that in Vista it has to do with these
"permitions" enhancements: popping the dialog to set environmental
variables needs administration priviledges now on Vista. I suspect that
explorer is not notifies any more for "security" reasons.
What is even more strange in Vista is the fact that stuff that worked in
XP is not even available under Vista. The most annoying such missing
feature is the inability to drop files/directories from explorer to a
command prompt! They have removed it from Vista again for "security"
reasons, and MS will not fix this despite the fact that so many
complains have been made about this :-(
I think that these "security" enhancements of Vista are just a
workaround for not having (or willing to develop) more decent APIs for
doing things :-(
George
PS: I moved to vista 64-bit because I wanted a supported 64-bit version
of windows (64-bit XP are unsupported by MS). But my impression so far
(about 2 weeks with them) is that they are much like XP with some
annoying things added: indexing (which searches my disk for ages),
a strange start menu (perhaps I am used to menus??), this UAC think that
pops every now and then and asks for permission (which is REALLY
ANNOYING! - not to mention that causes various bugs to any app that may
run in XP compatibility mode!) and an (ugly for me) UI.
They have made a lot of efford to add transparency, shadows, etc., but I
don't think that the result is so eye-pleasing. Not to mention that
everything disappears when an app that involves overlay is run (i.e. tv
capture programs)...
O/H MartinLemburg@UGS έγραψε:
Darren New
> 2. the developer assumes, that this DLL will know about this new or
> changed environment variable, but this scheme will fail, because (on
> Windows) a DLL has is own copy of the environment, like a kind of sub
> process.
Not according to Microsoft's API documentation.
http://msdn2.microsoft.com/en-us/library/ms682425.aspx
> I hoped stepping from W2k to XP, that MS could have implemented a kind
> of push or pull system for the case of a changing environment - "push"
> means, update the "main" processes environments, while "pull" means,
> that the processes gets a signal, that the environment changed and has
> to be updated.
They did. Since Windows 95.
http://msdn2.microsoft.com/en-us/library/ms725497.aspx
It's amazing how many features and abilities people complain about
Windows missing that are actually there and even easy to find.
Next up: "You can't delete open files."
--
Darren New / San Diego, CA, USA (PST)
His kernel fu is strong.
He studied at the Shao Linux Temple.
Darren New
> To check this,
Wow. This must be Open Source season. Microsoft *does* publish
documentation, tho. Go to MSDN.microsoft.com, and put
change notification environment variable
into the search box. You really don't have to try to guess how Windows
works, just because you don't have the source.
MartinLemburg@UGS
Since I have arranged to work as normal user, without administrative
rights/permissions, I can only change my own environment variables,
but no system environment variables.
I can't test the behaviour of Vista, but even on XP I experienced a
lot of restrictions.
Currently I can't rely on the environment variables of my "main"
explorer. Changing them as "Administrator" (runas feature), does not
update the "User" explorer, so a restart/reboot of the "User" explorer
is needed.
And even in the "good ages" working with administrative rights/
permissions, I experienced those barricades.
I installed e.g. Exceed and started it from the explorer and Exceed
claimed about missing "environmental" settings. Just because the
current explorer didn't know about the new environment variables,
created by the Exceed setup.
But perhabs this is all about fine tuning!
There are several possibilities to tune XP like to start each explorer
in a different process. So that one crashing explorer won't kill all
the others.
If this flag is switched on, than the desktop process (explorer) will
be parted from all other explorers started afterwards.
Perhabs that's the reason for my going over the barricades! ;-)
Best regards,
Martin Lemburg
UGS - Transforming the Process of Innovation
MartinLemburg@UGS
> It's amazing how many features and abilities people complain about
> Windows missing that are actually there and even easy to find.
yes, you are right!
But why is it possible, that people using M$ O$' all the time, since
many years, that are experienced in several matters, report different
experiences?
Because there are so many features, hidden tweaks, performance and
optimization tweaks, that all together could change the behaviour of M
$ O$' in a drastical way?
There is a default M$ O$ installation, but no standard behaviour after
customizing the installed M$ O$!
I reported my experiences, but perhabs in many experienced situations
are special start or border conditions involved.
In the case of used DLLs and the ability to let a DLL know, that an
environment variable was created or changed, .NET and MS Fortran DLLs
were involved, working with a plain WIN32 console executable written
in C++. And it didn't work!
So - if everything would be so plain and easy, life ... wouldn't be
such surprising any more, right?
;)
Best regards and a good evening,
Martin Lemburg
UGS - Transforming the Process of Innovation
On Apr 16, 5:42 pm, Darren New <d...@san.rr.com> wrote:
> MartinLemburg@UGS wrote:
> > 2. the developer assumes, that this DLL will know about this new or
> > changed environment variable, but this scheme will fail, because (on
> > Windows) a DLL has is own copy of the environment, like a kind of sub
> > process.
>
> Not according to Microsoft's API documentation.http://msdn2.microsoft.com/en-us/library/ms682425.aspx
>
> > I hoped stepping from W2k to XP, that MS could have implemented a kind
> > of push or pull system for the case of a changing environment - "push"
> > means, update the "main" processes environments, while "pull" means,
> > that the processes gets a signal, that the environment changed and has
> > to be updated.
>
> They did. Since Windows 95.http://msdn2.microsoft.com/en-us/library/ms725497.aspx
Georgios Petasis
> MartinLemburg@UGS wrote:
>> 2. the developer assumes, that this DLL will know about this new or
>> changed environment variable, but this scheme will fail, because (on
>> Windows) a DLL has is own copy of the environment, like a kind of sub
>> process.
>
> Not according to Microsoft's API documentation.
> http://msdn2.microsoft.com/en-us/library/ms682425.aspx
>
>
>> I hoped stepping from W2k to XP, that MS could have implemented a kind
>> of push or pull system for the case of a changing environment - "push"
>> means, update the "main" processes environments, while "pull" means,
>> that the processes gets a signal, that the environment changed and has
>> to be updated.
>
> They did. Since Windows 95.
> http://msdn2.microsoft.com/en-us/library/ms725497.aspx
>
> It's amazing how many features and abilities people complain about
> Windows missing that are actually there and even easy to find.
>
> Next up: "You can't delete open files."
>
Perhaps you are correct (and I usually complain before searching MSDN
:-)), but I did a little experiment:
a) I right-clicked "My Computer" icon, and got to the place
environmental variables are defined. (Yes, I did this with
administration priviledges). I defined the variable:
ZZZ_LAST_VARIABLE
b) I created a file named C:\Temp\print_env.tcl, which conatins the
following code:
console show
parray env
c) I started a command prompt from the start menu. Inside it, I wrote
"set". The new variable was there, as it is supposed to be. Good so far.
d) While keeping the dos window opened, I double-clicked on the file
print_env.tcl, from the explorer window. The new variable *wasn't* there.
Am I doing anything wrong? Shouldn't the variable be there, especially
since I run wish *after* the variable was defined? Even after the dos
prompt window?
A visual piece of evidence is at:
http://www.ellogon.org/~petasis/vista-tile/EnvironmentVistaBug.png
All these interesting things happen under my brand new Vista Ultimate
64-bit :-)
George
Darren New
> In the case of used DLLs and the ability to let a DLL know, that an
> environment variable was created or changed, .NET and MS Fortran DLLs
> were involved, working with a plain WIN32 console executable written
> in C++. And it didn't work!
Well, the change message goes to top-level Windows. If your DLL doesn't
have a top-level window of its own, you need to arrange to tell it to
re-read the environment variables itself. They get inherited when you
start the new process, just like UNIX, and you can't change them from
outside the process once they're passed in, just like UNIX.
> So - if everything would be so plain and easy, life ... wouldn't be
> such surprising any more, right?
I could go with fewer of those kinds of surprises in my life, yah. :-)
Alexandre Ferrieux
> Alexandre Ferrieux wrote:
> > To check this,
>
> Wow. This must be Open Source season. Microsoft *does* publish
> documentation, tho. Go to MSDN.microsoft.com, and put
> change notification environment variable
> into the search box.
I did, and received:
which doesn't help me a bit (25 hits of variously cryptic relationship
with the keywords).
> You really don't have to try to guess how Windows
> works, just because you don't have the source.
I do because the online documentation is unhelpful.
It is you right to have pleasure swimming through bloat-documentation.
It is my right to have other ways to heaven.
-Alex
Neil Madden
...
> a) I right-clicked "My Computer" icon, and got to the place
> environmental variables are defined. (Yes, I did this with
> administration priviledges). I defined the variable:
>
> ZZZ_LAST_VARIABLE
>
> b) I created a file named C:\Temp\print_env.tcl, which conatins the
> following code:
>
> console show
> parray env
>
> c) I started a command prompt from the start menu. Inside it, I wrote
> "set". The new variable was there, as it is supposed to be. Good so far.
>
> d) While keeping the dos window opened, I double-clicked on the file
> print_env.tcl, from the explorer window. The new variable *wasn't* there.
>
> Am I doing anything wrong? Shouldn't the variable be there, especially
> since I run wish *after* the variable was defined? Even after the dos
> prompt window?
From naively reading what others have written in this thread, perhaps
the Tcl DLL is being cached in memory the first time you run it and all
subsequent Tcl programs see the environment it had when it was first
loaded? Do you get this problem when you have just booted the system? --
e.g., boot Windows fresh, define a new environment variable, and then
run wish for the first time and see if it is visible. If it is a problem
with the DLL, then perhaps as a workaround you can use a tclkit or other
statically-linked Tcl interpreter?
-- Neil
Darren New
> Currently I can't rely on the environment variables of my "main"
> explorer. Changing them as "Administrator" (runas feature), does not
> update the "User" explorer, so a restart/reboot of the "User" explorer
> is needed.
This is really no different from how environment variables work
everywhere else. Everyone gets a copy of the environment when they
start. If you need to be changing things and seeing the changes, there
are a gazillion ways that work well, including the file system, the
registry, named pipes, global events, and posting messages directly to
windows. You're banging on a square peg with a round hammer. Using
environment variables to talk to a DLL you just linked into your own
address space is just silly.
Jeff Hobbs
> Because Vista environmental variable handling is awful?
> After many hours of various experiments, I realised that the environment
> when running tclapp (and this is windows explorer!) was not updated with
> the new environmental variable (TCLAPP_PKGPATH).
>
> Under my brand new vista 64-bit, If I opened a dos prompt, the variable
> was there. But double-clicking a tcl script from explorer was running
> without the variable!
>
> A simple reboot solved the problem. But I still want this to be a
> command line option in tclapp. I have lost many many hours in setting
> this variable to a proper value and making tclapp work!
This sounds a bit like a Vista bug to me (the Explorer should be made
aware of environment variable changes through the registry broadcast ...
but it may have something to do with new security measures and/or the
weird 32/64 bit reg entry masking).
In a side note, we noted to George that TDK 4.0 has an improved
mechanism for handling this.
Jeff
Georgios Petasis
I have tried this, and no the new variable is not visible. I even tried
running the ActiveTcl base kits (base-tcl-thread-win32-ix86.exe &
base-tk-thread-win32-ix86.exe) which are not entirelly static, but have
dependencies only on system dlls (i.e. not depending on tcl.dll), but
again the new variable is not visible within tcl. The command prompt
can see the new variable as expected. Finally, the same happens with
variables defined at the system level & variables defined at the user
level. Isn't it strange?
George
Georgios Petasis
a) Define a new environmental varible in vista.
b) Start a command prompt, for the start menu. The new variable is visible.
c) Start an explorer window (no matter from where, the start menu, the
desktop, the quick lunch, etc...)
d) Start any tcl interpreter from this explorer window. The new variable
*is not visible*.
e) Run a tcl interpreter from the *start menu*. Now, the new variable
*is visible*.
f) Starting again a tcl interpreter from the explorer, it does not see
the new variable.
g) Starting command prompt from the explorer window, laso *does not see
the new variable*.
So, in order for tcl (and other programs) to see newly defined
variables, either the system must be rebooted, or the program must be
started from the start menu!
George
O/H Georgios Petasis έγραψε:
MartinLemburg@UGS
so the conclusion is, that ...
1. the desktop process (explorer) providing the start menu and the
desktop is updated, or holds the most current set of environment
variables
2. no other application (e.g. explorer) got to know the most current
set of environment variables
3. applications started from the desktop process are up to date
4. applications started from another application (e.g. explorer) are
not up to date.
Fine the sight's getting clearer.
This behaviour is the same on my MS Windows XP Prof. SP2 system!
But I've switched on the explorer folder option "launch folder windows
in a separate process"! This may be a reason for the system behaviour.
Perhabs in VISTA this is the default?
Best regards,
Martin Lemburg
UGS - Transforming the Process of Innovation
On Apr 17, 3:53 pm, Georgios Petasis <peta...@iit.demokritos.gr>
wrote:
Darren New
> So, in order for tcl (and other programs) to see newly defined
> variables, either the system must be rebooted,
I'm guessing you could just log out and log back in again to restart the
top-level explorer.
Georgios Petasis
> Hello George,
>
> so the conclusion is, that ...
>
> 1. the desktop process (explorer) providing the start menu and the
> desktop is updated, or holds the most current set of environment
> variables
> 2. no other application (e.g. explorer) got to know the most current
> set of environment variables
> 3. applications started from the desktop process are up to date
> 4. applications started from another application (e.g. explorer) are
> not up to date.
>
> Fine the sight's getting clearer.
>
> This behaviour is the same on my MS Windows XP Prof. SP2 system!
>
> But I've switched on the explorer folder option "launch folder windows
> in a separate process"! This may be a reason for the system behaviour.
> Perhabs in VISTA this is the default?
No, it is not the default, but I always enable this in all versions of
windows I use. The reason is that if an explorer window is not
responding to have the potential to kill it without loosing the whole
desktop :-)
George
Alexandre Ferrieux
> Georgios Petasis wrote:
> > So, in order for tcl (and other programs) to see newly defined
> > variables, either the system must be rebooted,
>
> I'm guessing you could just log out and log back in again to restart the
> top-level explorer.
You're *guessing* ? No smart documentation pointer here ?
Just kidding.
-Alex
Darren New
> You're *guessing* ? No smart documentation pointer here ?
Heh. I guess I deserved that. ;-)
John Ellard
Have you tried refreshing the Windows Explorer window? Or, shutting it
down and opening a new explorer window?
Before I'd conclude that I need to reboot Windows, I'd log out and log
back in (assuming that refresh or a new explorer window doesn't work).
John