1001コメント301KB

vista対策

■ このスレッドは過去ログ倉庫に格納されています

0001デフォルトの名無しさん

2006/11/06(月) 20:41:33

まとめたい

00022

2006/11/06(月) 20:43:04

00033

2006/11/06(月) 20:43:15

00044

2006/11/06(月) 20:49:04

00055

2006/11/06(月) 22:22:22

見た目はキリ番
頭脳は・・

0006デフォルトの名無しさん

2006/11/06(月) 23:12:01

つうか、別にいいんじゃね？とくに対策とかって

とりあえず評価版いれてみれば？

0007デフォルトの名無しさん

2006/11/07(火) 01:06:07

最大の対策は24ヶ月ほど入れないことだなw

0008デフォルトの名無しさん

2006/11/07(火) 03:01:11

>>1
何かまとめれアホ

0009デフォルトの名無しさん

2006/11/07(火) 04:40:45

フォルダ配置が全然変わったから注意

例：C:\Document and SettingsフォルダなくなってC:\User

とか

0010デフォルトの名無しさん

2006/11/07(火) 06:09:51

>>9
そのフォルダをじかに参照するソフトは、それはそれで問題あるかも。
ちゃんとやるにはレジストリから実際のフォルダを引っ張ってくるでしょ。
そしてレジストリから引っ張ってくるならその違いは問題になっていないはず。

0011デフォルトの名無しさん

2006/11/07(火) 06:33:05

>>10
C:¥Document and Settings フォルダのパスを正式に取得する方法は実はなかったりする。

C:¥Document and Settings¥hoge フォルダの CSIDL あっても
C:¥Document and Settings フォルダの CSIDL はない罠。

0012デフォルトの名無しさん

2006/11/07(火) 08:41:36

INIファイルはどこにおけばいいですか？
もうINIはだめですか？

0013デフォルトの名無しさん

2006/11/07(火) 10:26:58

>>9
何?もしかしてロングネームや空白使わないよ～にしよ～的動きがあるのか?

0014デフォルトの名無しさん

2006/11/07(火) 13:19:50

対策？何を対策すると言うの？
ああ、データの位置などか。それは確かに面倒だな。
でも、置換ですぐに対処できると思うが。

0015デフォルトの名無しさん

2006/11/07(火) 13:26:18

Document and Settings とかのユーザフォルダなんてOS毎に変わるんだから。
普通はAPIで取ってるよね？

0016デフォルトの名無しさん

2006/11/07(火) 16:18:56

>>12
%APPDATA%
にフォルダ作ってそこにini等の設定ファイルを置けばいいのでは。

0017デフォルトの名無しさん

2006/11/07(火) 17:52:45

いまどきiniかよ
XMLで書けよぷげらっちょ

0018デフォルトの名無しさん

2006/11/07(火) 19:12:17

>>16
ありがとう。
APPDATAはユーザ別にデータ持たせたい場合ですが、ユーザごとに
共通のデータはどこに置いたらいいのでしょうか？

0019デフォルトの名無しさん

2006/11/07(火) 20:04:10

>>17
iniの方が書き換えが楽

0020デフォルトの名無しさん

2006/11/07(火) 21:10:00

なんでもXMLにすればいいと思ってる学生ですからw

0021デフォルトの名無しさん

2006/11/07(火) 21:14:35

>>19
UAC環境下でProgram Files配下のiniを書き換えようとするとマジはまるぞ。

0022デフォルトの名無しさん

2006/11/07(火) 21:19:57

>>19
プログラムからの読み取りは、ライブラリが充実しているから、XMLのほうが楽だと思う。

0023デフォルトの名無しさん

2006/11/07(火) 23:50:56

俺的には2000→XPの時よりやることが少なかった。
はっきり言って意外だったが助かった。

0024デフォルトの名無しさん

2006/11/08(水) 08:19:43

>>18
%ALLUSERSPROFILE%\Application Data

0025デフォルトの名無しさん

2006/11/08(水) 11:00:23

XMLなら可変データも持てるしiniより自由度高いし
.netならアクセスも超楽チン
iniなんて終わってる

0026デフォルトの名無しさん

2006/11/08(水) 12:52:10

vista対策関係ないからなあ、他でやってけろ

0027デフォルトの名無しさん

2006/11/08(水) 16:35:45

もうすぐVistaが出るが…
http://pc8.2ch.net/test/read.cgi/tech/1157349228/l50

0028デフォルトの名無しさん

2006/11/08(水) 17:31:22

そっちもこっちも閑散としてるってことは、ようするにほとんど
動いちゃうんだろうな。

それともvista対策って、vistaからできる新機能の使い方の
勉強でもしようかってことなのか？

0029デフォルトの名無しさん

2006/11/08(水) 22:41:54

>>24
Vistaでは%SystemDrive%\ProgramDataになっていますが何か。
だからAPIを使えと(ry
# そのAPIすらSHGetKnownFolderPathなんてのが新設されて今後はこっち使えとか
# 言ってるし。もう何を信じたらいいのやら

0030デフォルトの名無しさん

2006/11/08(水) 23:24:24

HKLMにRegCreateKeyExでキーを作ろうとすると権限不足で作れない。
しかもERROR_SUCCESSを返してきやがる。
MANIFESTでexe起動時に管理者権限に昇格するダイアログを表示させて
権限を得ればいいらしいけど、エラーくらい正しく返してきやがれorz

0031デフォルトの名無しさん

2006/11/09(木) 01:28:22

HKLMへの書き込みに失敗するとエラーダイアログを出しまくったり
インストールに失敗したりする馬鹿なインストーラ対策。
asInvokerなマニフェストでいいから付けておけば権限取得も必要ないし
変な偽装はやめてくれるよ。

0032デフォルトの名無しさん

2006/11/09(木) 01:32:52

> 権限取得も必要ないし
あ、ちゃんとエラーを返してくれるはずという意味で
本当に書き込みたいならもちろん権限取得が必要。

0033デフォルトの名無しさん

2006/11/09(木) 14:03:05

UACが有効だと、Program files下にインストールした
ファイルをアンインストール（DeleteFile）してもファイル
が消えないです。

こういう場合はどうするのがセオリーでしょうか？
（ユーザー権限はAdminです）

UACを無効にすればひとまず回避できますが、ユーザーに
それをお願いするのもイマイチですし…

0034デフォルトの名無しさん

2006/11/09(木) 17:11:03

そのアンインストーラの実行ファイルの名前に
setupかinstallという文字列が入ってると、
昇格ダイアログを出してくれるらしい。

0035デフォルトの名無しさん

2006/11/09(木) 17:35:25

vista対策？ああ

//バージョンごとに処理を切り分ける
if(osver == WIN9X)
{
　...
}
else if(osver == WIN2K || osver == WINXP)
{
　...
}

ってなってるところをVistaも通るようにする処理だな。

漏れのプログラムこんなの大杉orz

0036デフォルトの名無しさん

2006/11/10(金) 19:49:06

1.UACの動作する状況へのインストール(C:\Progran files以下など)
2.メディアから起動するランチャーで実行ファイルを起動すると、UACが働かずに
インストールフォルダにデータなどが生成される。
3.実行ファイルを直接(あるいはショートカットなどから)起動すると、UACが働き
互換性フォルダが生成され、その中にデータなどが生成される。
4.ランチャーで実行ファイルを起動すると、UACが働かないのでインストール
フォルダ内のデータのみを読み込み・更新する。
5.実行ファイルを直接(あるいはショートカットなどから)起動すると、UACが働き
インストールフォルダ・互換性フォルダ両方のデータを参照する。
　同一のファイル名が存在する場合には互換性フォルダ内のファイルが優先される。
新規作成・更新は互換性フォルダにのみ適用

以上転載終わり。
なぁこれどうやって対処したらいいと思う？βの時に散々対応しようとして挫折したんだが。
無理矢理、ランチャーからプログラムの実行ユーザーを偽装しようとしても上手く行かないし。
互換性フォルダ見に行くようにしようとも考えたけど、UAC切ってるユーザーもあること考えるとそれもどうかと思うし。
MSの言うとおりUser下にフォルダ作るのもユーザーの使い勝手からあまりやりたくないんだよねぇ

0037デフォルトの名無しさん

2006/11/10(金) 22:01:39

いやー、VistaからはUser\アカウント　の下にインストールを
促すよう変更しようかと思ってる。

0038デフォルトの名無しさん

2006/11/11(土) 00:25:03

>>33
アンインストーラにmanifest付けて権限を取得させる。
>>34
それはあくまでレガシーなアンインストーラのための救済策で、
スレタイ通り新規にVista対策するならやるべきではない。

0039デフォルトの名無しさん

2006/11/11(土) 00:29:15

> やるべきではない。
って言うとアンインストーラのファイル名にsetupとか含めるべきではないと読めちゃうな。
訂正
スレタイ通り新規にVista対策するなら頼るべきではない。
インストーラ検出はグループポリシー等で無効にされている可能性もあるし
64bitアプリでは最初から効かない。

0040デフォルトの名無しさん

2006/11/11(土) 01:23:25

>>38
＞アンインストーラにmanifest付けて権限を取得させる。

済みませんが、やり方をもう少し詳しく…。
アンインストーラ　manifest　vista でググってもピンと来ませんでした。
お願いします。

0041デフォルトの名無しさん

2006/11/11(土) 02:01:41

requestedExecutionLevel
でググってみそ

0042デフォルトの名無しさん

2006/11/11(土) 03:09:47

>>37
プログラムをUser\アカウントに入れるですか（汗
それはそれで一つの解決策ではありますねｗ

う～ん、ただある程度大きいソフトだとそこに入れるのも問題あるし
やっぱりvistaではランチャーからの起動は諦めるしかないのかなぁor2

0043デフォルトの名無しさん

2006/11/11(土) 03:13:27

ランチャーは自作? 他人が作ったもの?

0044デフォルトの名無しさん

2006/11/11(土) 10:47:26

>>41
ありがとうございます。

0045デフォルトの名無しさん

2006/11/11(土) 11:58:09

>>43
Quick Launch

0046デフォルトの名無しさん

2006/11/11(土) 14:25:29

クイック起動の実体って単なるショートカットじゃなかったっけ?
クイック起動にショートカット放り込んで試してみたけどちゃんとUAC効いて
互換性フォルダを参照したぞ?

0047デフォルトの名無しさん

2006/11/11(土) 15:27:05

コピペ元はこれか。
http://idol.bbspink.com/test/read.cgi/hgame/1090858757/822
つまりランチャーってのはautorunで起動されるCD/DVD内のプログラムってことね。
130cmのサポートページによると実行ファイルの名前がsetup.exeだから
http://130cm.jp/support/support.html#07
インストーラ検出によってランチャーが管理者として実行されるので互換性フォルダが
見えなくなるってことでおｋ? ＞本物の>>36

0048デフォルトの名無しさん

2006/11/12(日) 02:30:52

>>47と仮定して対策を書くと
・ランチャーのファイル名を変えるとかmanifestを付けるとしかしてインストーラとして
　検出されないようにする
・インストーラを別exeに分ける
で何も問題ないと思うが。
> MSの言うとおりUser下にフォルダ作るのもユーザーの使い勝手からあまりやりたく
> ないんだよねぇ
標準ユーザーでUAC切るとProgram Filesの下には書き込めないことも
頭の片隅くらいにはとどめておいてくれ。

0049デフォルトの名無しさん

2006/11/12(日) 02:36:58

> 標準ユーザーでUAC切るとProgram Filesの下には書き込めない
管理者として実行されているインストーラからは書き込めるからプログラムは
Program Filesにインストールしてもかまわないけど、
インストール後に実行ファイルから設定を書けるとは限らないってこと。

0050デフォルトの名無しさん

2006/11/12(日) 13:46:41

>>47
コピペはそれです。ただそれと同じ事象を6月頃には把握しててそのころにいろいろ実験してて投げちゃってた。
ちょうどその事象のことをそこで見たんで思い出してコピペして聞いて見たって感じです。
事象としては、ランチャーから起動したプログラムはランチャーの実行権限を引き継いでしまうってことですね。
なので、setup.exeから何かプログラムを起動するとsetup権限で起動してしまう。

>>48
マニフェストについては確か上手く行かなかったと思う。
実行時にメッセージが出ちゃうか、呼ばれた方のプログラムが起動出来なかったかだったと思う。
ランチャーの名前を別にしてセットアップを別exeにするのも、確かセットアップの権限が変更されないで呼んでも上手く動かなかったと思う。

ただ調べたのが6月ごろで今のRC版では確かめてないのと当時のテスト結果が見つからないんでもしかすると勘違いで出来るのかも。
あとでもう一度検証してみます。

>標準ユーザーでUAC切るとProgram Filesの下には書き込めないことも
>頭の片隅くらいにはとどめておいてくれ。
まぁそれはXPでもそうだしなぁｗ
ただユーザーとしてはデータを分散して置かれるのってあまり喜ばしいことじゃ無いと思うんだけどどうなんだろ。
周知徹底が出来て、みんなUser下に置くのが当然と思うようになってればいいんだけど、
結局XPでも浸透しなかったし。浸透しないと使えないけど、使わないから浸透しない。困った物ですねぇ

0051デフォルトの名無しさん

2006/11/12(日) 17:14:50

> マニフェストについては確か上手く行かなかったと思う。
うまく動くことはこちらでは確認済み(RC2 Build 5744)。何か大幅に勘違いしてるか
ベータの不具合に当たったと思われ
とりあえずこことか参照。
http://blogs.wankuma.com/jitta/archive/2006/09/26/39667.aspx
あとasInvokerなマニフェストを使ってる実例。
http://kage.monazilla.org/ のインストーラ
> 実行時にメッセージが出ちゃうか、呼ばれた方のプログラムが起動出来なかったかだったと思う。
ちなみにどんなメッセージが出る?

> まぁそれはXPでもそうだしなぁｗ
XPと違う点としては、マニフェストを付けると互換性フォルダは無効になるので、
asInvokerなマニフェストを付けるとたとえ管理者ユーザーでも(UACが有効なら)
Program Filesには書けなくなる。
だからUsers配下へ設定を書きに行くように変更しない手抜き対応なら
(ランチャから起動される実行ファイルのほうには)マニフェストをつけないほうがいいよ

0052デフォルトの名無しさん

2006/11/12(日) 17:26:29

> ランチャーの名前を別にしてセットアップを別exeにするのも、
> 確かセットアップの権限が変更されないで
セットアップのほうはインストーラとして検出されるようにするかrequiredAdministratorな
マニフェストをつけないとだめだよ。
あとセットアップを起動するときはCreateProcessじゃなくてShellExexuteを使わないと
ERROR_ELEVATION_REQUIREDと怒られて起動できない。

まとめると
・ランチャーにはasInvokerなマニフェストをつける
・インストーラにはrequiredAdministratorなマニフェストをつける
・実行ファイルにはマニフェストをつけない
・ランチャーからは互換性フォルダが見えなくなるので注意

0053デフォルトの名無しさん

2006/11/13(月) 02:12:23

>>51
今は日本語にしてくれる人が居るんだね、当時は英語だったんで辞書引きながら見てたよ。
そうそう、確かマニフェストだと、権限は引き継ぎか上位への変更だけで、
インストール権限から通常権限に下げられないのと、権限が変更される場合にUACのメッセージが出るからだったかな。
常時動かすのに権限変更のメッセージは許容出来なかったんで。（あと実行プログラムを常時adminで動かすのに抵抗もあったし）
それから、呼び出しは最初はShellExecuteにしてたけどこれだと権限の変更が出来なかったんで、
CreateProcessを使ったけど状況が変わらず。CreateProcessAsUserでユーザー偽装しようとしたら動きさえしなかったって感じだった。

確かによくよく考えてみると>>52のでなら上手く行く気もする。
当時、インストーラから実行するのに囚われすぎてて考えが及ばなかったのかも。
あとで試してみるよ。

0054デフォルトの名無しさん

2006/11/13(月) 09:17:08

Program files下へインストールするアプリが、Program files下へ
設定を書き込んだり消したりするようなつくりだと、ユーザーが
UACを切ったり付けたりしたら挙動に矛盾が起きないかな？

それを解消するようなマニフェストってある？

0055デフォルトの名無しさん

2006/11/13(月) 14:42:44

>>54
どうしても矛盾を起こしたくないならrequiredAdministratorを使うしかないと思うけど。
ただUACのON/OFFはOS挙動だしユーザーが変更する部分だから
上の例の様に、通常状態で挙動が矛盾してしまうならともかく
そこまで気にする必要は無いんじゃないかな。
もしくはマイクロソフトの言うとおりに、自前で直接User下に放り込むか。

もともとUACってProgram filesに設定を置くなって言うマイクロソフトのガイドラインに
誰も従わなかったんで強行策に出たって感じだろうし、vista出てしばらくは混乱するだろうね。

0056デフォルトの名無しさん

2006/11/14(火) 00:27:10

俺的には
>>37
の対処法がステキすぎる

0057デフォルトの名無しさん

2006/11/14(火) 01:00:07

> 常時動かすのに権限変更のメッセージは許容出来なかったんで。（あと実行
> プログラムを常時adminで動かすのに抵抗もあったし）
requiredAdministratorなマニフェストで試してなかった?
asInvokerなマニフェストではUACのダイアログは出ないから大丈夫。

> 呼び出しは最初はShellExecuteにしてたけどこれだと権限の変更が出来なかったんで、
起動するexeにマニフェストが付いてないとだめということになってる。
(付いてなくても権限上昇できるチートがWin32 APIスレのPart 46に出てたが)

> CreateProcessAsUserでユーザー偽装しようとしたら動きさえしなかったって感じだった。
それは純正のrunasでもできないので仕様だと思われ

0058デフォルトの名無しさん

2006/11/14(火) 01:05:10

>>54
MSの推奨は全部の実行ファイルにマニフェストを付けて
(これで互換性フォルダが無効になるので互換性フォルダにかかわる矛盾も生じない)、
設定はProgram Filesに書き込まないこと。
もしProgram Filesへ書き込む設計を維持しつつ、という意味ならMSはそれを
やめさせたいんだからそんなものあるわけない。
互換性フォルダはあくまでレガシーなアプリのための救済策。

0059デフォルトの名無しさん

2006/11/14(火) 01:30:44

> どうしても矛盾を起こしたくないならrequiredAdministratorを使うしかないと思うけど。
標準ユーザーでUACオフにしたとき困るから
> UACを切ったり付けたりしたら
という前提では不適切かも。>>54が標準ユーザーの場合まで考慮してるのかどうかは
知らないけど

0060デフォルトの名無しさん

2006/11/14(火) 09:19:17

setupの文字を含んだインストーラからProgram files下へ
インストールして初回起動はsetpu.exeがランチ。
次回はデスクトップのショートカットから（setupの文字を
含まない）実行ファイルを起動したらそれだけで矛盾し
ちゃわない？

新しいアプリは何らかの対策を施せるけど、古いアプリを
継続して使いたいひとはUAC切るかインストール場所を
Userの下にするかすればOKなのかな？　プログラム板的
には板違いの話かも知れないけど、古いアプリを暫定で
サポートする時の参考になれば思って。

0061デフォルトの名無しさん

2006/11/14(火) 12:14:20

>>57
すまぬ。ちょっと前提が抜けてね。
>インストール権限から
ということでランチャーはセットアップを兼ねてるものです。
なのでasInvokerを付けると、そのままインストール権限が持ち越しされてしまう（当時確認済み）
つーかマニフェストに通常権限にする命令があればそれで事足りるのになんで無いんだよ！！って話です。
なので>>52の手法の様にランチャーが通常権限になるようにしていればasInvokerでよかったんでしょうね。

0062デフォルトの名無しさん

2006/11/14(火) 19:47:12

>>60
とりあえず初回起動はインストーラから行わないように運用で回避してる

0063デフォルトの名無しさん

2006/11/15(水) 15:52:14

アプリからファイル保存できない場所って、Program Files以下以外にありますか？
Windows以下もダメだろうけど、判断できるようなAPIってないですかねぇ？

0064デフォルトの名無しさん

2006/11/15(水) 20:35:35

AccessCheckとかで判断できないか?
判断するAPIまで互換性フォルダにだまされるかもしれないけど(試してない)。

0065デフォルトの名無しさん

2006/11/15(水) 21:27:36

おれも判定方法知りたい。ひとまずVistaでProgram filesが含まれていたら、
でやっとくか。

0066デフォルトの名無しさん

2006/11/18(土) 22:03:29

AccessCheckで判断できた。
ただしレガシーアプリが作成したフォルダやレガシーアプリが
書き込んだことのあるファイルは互換性フォルダにリダイレクトされるせいか
以後、書き込み可能だと判断されるようになる。
%ProgramFiles%のルートに書き込めるかどうかで判断したほうがいいかも。
しかしAccessCheckは呼び出すのがめちゃくちゃ面倒くさいな

0067デフォルトの名無しさん

2006/11/20(月) 03:36:06

>>60
既にあるプログラムについては、諦めて普通にOSの互換性の機能使った方がいい気がする。
プログラムのプロパティ内の互換性タブに、
特権レベルの設定として「管理者としてこのプログラムを実行する」っていうのがあるのは
多分MSとしてはコレ使えってことだと思われ。

ただ一番楽なのはやっぱりUAC切れってところかも知れんがｗ

0068デフォルトの名無しさん

2006/11/20(月) 16:30:30

独自のアップデータをVistaで作りたい場合、どうするのが正解？

権限昇格無しにProgram Filesのファイルを書き換えようとすると、ファイルの
上書きに失敗するし、かといって、requiredAdministratorなマニフェストを付加
すると起動のたびに権限昇格のダイアログが開いてとてもウザイんですけど・・・

>>37の対処法なら問題ないんだけどさ・・・

0069デフォルトの名無しさん

2006/11/20(月) 18:00:22

アップデートを別プログラムにして必要なときに呼び出すようにするのがいいんじゃないのかな？
そうすればアップデート時だけダイアログが出る感じになるし。

もともとUACってProgram Filesを勝手に弄られることによるセキュリティの低下を防ぐのがコンセプトだから
ダイアログを出さないようにって言うのは出来ちゃいけないことだろうし。
随時データを書き換えるって言うのは出来なくなっちゃうだろうけど。

ちなみにUACではアップデートもちゃんと考えてるらしく、
プログラム名をupdate.exeにしたら権限変わった。
なので手動での差分当てレベルなら今まで通りでいいと思う。

007068

2006/11/20(月) 18:32:17

>>69 情報ありがとう

いままでアップデータ自体をアップデートしたい時、
アップデータEXEが終了し親EXEに制御が移ったときに、
ダウンロードされたアップデータEXEのアップデートファイルを
上書きしてたんだけど、それが出来なくなるってのは
回避できないっすよね？

コレを可能にしようとすると親EXEにも・・・となって堂々巡りに・・・

0071デフォルトの名無しさん

2006/11/20(月) 19:59:14

Vistaってルート直下に作るのはUACが出張ってくる？

0072デフォルトの名無しさん

2006/11/20(月) 23:40:22

>>68
アップデータを別exeに分けて「更新」ボタンには盾アイコンをつける。
自動更新が必要ならサービスをインストールする。
常駐プロセスを増やしたくないならタスクに登録する(最近のQuickTimeと一緒に
入ってくるASUでもやってる)。
>>69
> プログラム名をupdate.exeにしたら権限変わった。
それもsetup.exeと一緒でインストーラ検出の機能なので無効な場合もある。一応。
>>70
APIスレで自分自身を削除する話が出てるからその応用で
親exeに戻らず自分の分身を作ってその分身に上書きすればいい。
子プロセスは権限を引き継ぐから。
>>71
ルート直下は誰でも作れて作成者はフルアクセスが得られるけど他のユーザーは
読み取りのみ。XPと同じ。

0073デフォルトの名無しさん

2006/11/21(火) 17:40:54

>>72
MoveFileEx MOVEFILE_DELAY_UNTIL_REBOOTが失敗するよ(ノД`)

0074デフォルトの名無しさん

2006/11/21(火) 19:07:37

管理者権限に昇格したらイケタ！

0075デフォルトの名無しさん

2006/11/21(火) 19:59:35

MOVEFILE_DELAY_UNTIL_REBOOTは再起動のときログイン前に読める位置
(HKEY_LOCAL_MACHINE配下)のレジストリに値を書き込むからな

0076デフォルトの名無しさん

2006/11/24(金) 12:26:18

いいこと思いついたぜ。
プログラム名をsetup.exeにすれば問題全部解決出来る！！！１１！！！！！１！

0077デフォルトの名無しさん

2006/11/26(日) 21:44:07

奇才現る

0078デフォルトの名無しさん

2006/11/27(月) 13:07:43

あるアプリケーションをネットワークドライブから管理者で実行すると、
自分自身のパスのドライブレターがUNCになっちゃうんだけど回避方法無いかな？

（一般ユーザ）
z:\xxx\HOGE.EXE ←実行
↓
z:\xxx\HOGE.EXE ←アプリが判断した自分のパス

（管理者）
z:\xxx\HOGE.EXE ←実行
↓
\\(IP)\zzz\xxx\HOGE.EXE ←アプリが判断した自分のパス

UACを切らずになんとか・・・

0079デフォルトの名無しさん

2006/11/27(月) 16:44:09

プログラム名をsetup.exeにする

008078

2006/11/27(月) 17:22:58

>>79
setup.exeでも同じ結果でした。

その上、DriveCmboBoxでネットワークドライブが選択できない状態で、
さらにアウアウになってます。

0081デフォルトの名無しさん

2006/11/27(月) 17:26:12

setup.exe敗れたり・・・

0082デフォルトの名無しさん

2006/11/27(月) 21:44:16

管理者として実行されると別ユーザーのような状態になるから
そもそも実行もとの一般ユーザと同じドライブがマッピングされてるとは限らない

008378

2006/11/27(月) 22:07:58

>>82
つまり回避方法はないということ？

管理者モードで動作するネットワークアプリは使えなくなる可能性があるのか・・・

0084デフォルトの名無しさん

2006/11/27(月) 22:40:04

ローカルセキュリティポリシーが効くんじゃなかったかなあ

0085デフォルトの名無しさん

2006/11/28(火) 03:06:42

>>83
そもそもXPで別ユーザー実行したときはどうしてたの? そんなのサポート外?
XPだとこんなの出たけど。
---------------------------
Z:\pwd.exe
---------------------------
Z:\pwd.exe

指定されたパスは存在しません。

パスが正しいか確認してください。
---------------------------
OK
---------------------------

008678

2006/11/28(火) 11:12:34

>>84
kwsk

>>85
XPではサポート外というか起動出来ないようにして、管理者権限のユーザのみ使用可能にしてました。

レジストリ（LOCAL_MACHINE等）をいじったりするので、管理者権限無いと
動作する意味がないので。

0087デフォルトの名無しさん

2006/12/03(日) 19:45:21

おれが採った方法：インストール時にインストールしたディレクトリをEveryone/Full-controlにしてしまう。

Windows95時代からマイナーチェンジのみ繰り返しているソフトで、プログラムをインストールしたディレクトリ
自身に設定ファイル(要Write)を置いているため、苦肉の策。
インストーラはInstallShield3(古っ！)を使っているが、そのスクリプト中からLaunchAppAndWait()で、インスト
ールディレクトリのセキュリティーを設定(SetNamedSecurityInfo())するプログラムを呼び出す。
これで、exeと同じディレクトリ(Program files下)にある設定ファイルへの書き込みも、アップデートプログラム
での書き込みもＯＫ！

良い子は真似しないように。

P.S.
UACよりもWinHlp32( .hlp)が使えないのに泣いた・・・・・

0088デフォルトの名無しさん

2006/12/21(木) 21:49:14

>>76
インストーラみたいなファイル名なのにインストールしないで終了すると
プログラム互換性アシスタントに文句言われるよ

0089デフォルトの名無しさん

2006/12/22(金) 01:00:12

フルコントロールにしなくても、読み書き変更やファイル作成なんかの権限を与えれば十分だと思うが。

0090デフォルトの名無しさん

2006/12/23(土) 00:53:49

>>53
> CreateProcessAsUserでユーザー偽装しようとしたら動きさえしなかった
CreateProcessWithTokenWで降格に成功した。
トークンはエクスプローラのウィンドウからGetWindowThreadProcessId→
OpenProcess→OpenProcessToken→DuplicateTokenExで引っ張ってきた。
すでにログオン済みのユーザなので
プロファイルのロードや環境ブロックの作成は不要

0091デフォルトの名無しさん

2006/12/25(月) 21:09:06

>>88
＞インストールしないで終了する
ってどう判断してるの？

■ このスレッドは過去ログ倉庫に格納されています