[讨论]关于VXD中的地址

发信人: wwwwww (困困), 信区: Programming 
标  题: 关于VXD的问题 
发信站: BBS 水木清华站 (Mon Feb 16 02:46:39 1998) 
 
VXD相对于所有的应用程序都是全局的， 
也就是说应用程序可以直接存取VXD中的 
全局变量。这是经过证实的。 
现在的疑问是： 
  1。所有的VXD都在同一线性地址空间里吗？ 
     这个线性地址空间的长度最多是多少呢？ 
     如果是4GB，那别的应用程序又怎么能看得见这些VXD呢？ 
     如果看不见那是不可能实现前面所说的数据共享的。 
  2。VXD也有数据段，代码段吧？因为在写VXD时就有这些概念， 
     这样可以利于维护代码段的只读特性。想问的是：这些数据段， 
     和代码段也是在同一线性地址空间里了？ 
      
                
 
-- 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 166.111.8.130] 
发信人: Cohen (Tommy), 信区: Programming 
标  题: Re: 关于VXD的问题 
发信站: BBS 水木清华站 (Mon Feb 16 15:19:08 1998) 
 
【 在 wwwwww (困困) 的大作中提到: 】 
∶ VXD相对于所有的应用程序都是全局的， 
∶ 也就是说应用程序可以直接存取VXD中的 
∶ 全局变量。这是经过证实的。 
∶ 现在的疑问是： 
∶   1。所有的VXD都在同一线性地址空间里吗?nbsp;
                    ^^^^^^^^^^^^^^^^^^^^ 好象是这样的，从微软提供的资料看 
                                         VXD占用了2G以上的系统空间，而应用程序 
                                         空间在2G以下  ?nbsp;
∶      这个线性地址空间的长度最多是多少呢？ 
∶      如果是4GB，那别的应用程序又怎么能看得见这些VXD呢？ 
∶      如果看不见那是不可能实现前面所说的数据共享的。 
∶   2。VXD也有数据段，代码段吧？因为在写VXD时就有这些概念， 
∶      这样可以利于维护代码段的只读特性。想问的是：这些数据段， 
∶      和代码段也是在同一线性地址空间里了？ 
 
 
-- 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 166.111.74.242] 
发信人: suxm (笨笨), 信区: Programming 
标  题: Re: 关于VXD的问题 
发信站: BBS 水木清华站 (Mon Feb 16 16:40:32 1998) 
 
【 在 wwwwww (困困) 的大作中提到: 】 
∶ VXD相对于所有的应用程序都是全局的， 
∶ 也就是说应用程序可以直接存取VXD中的 
∶ 全局变量。这是经过证实的。 
                ~~~~~~~~ 
               的确是这样的 
 
∶ 现在的疑问是： 
∶   1。所有的VXD都在同一线性地址空间里吗？ 
                   ~~~~~~~~~~~~~~~~~  
                           是  
 
∶      这个线性地址空间的长度最多是多少呢？ 
                         ~~~~~~~~~~~~~ 
                          2GB 
 
∶      如果是4GB，那别的应用程序又怎么能看得见这些VXD呢？ 
∶      如果看不见那是不可能实现前面所说的数据共享的。 
 
   每一个应用程序的前2GB空间都有一份系统VXD的拷贝。 
   这些拷贝映射为同一内存RAM地址。 
   这样说来应用程序只能占用2GB-----4GB之间的地址空间了。 
 
 
∶   2。VXD也有数据段，代码段吧？因为在写VXD时就有这些概念， 
            ~~~~~~~~~~~~~~~~ 
            cs=ds=ss，在flat mode下请忘记段的概念，虽然CPU 
            仍在防护情况下使用着段 
 
∶      这样可以利于维护代码段的只读特性。想问的是：这些数据段， 
∶      和代码段也是在同一线性地址空间里了？ 
                   ~~~~~~~~~~~~~~~~~ 
                  因为CS=DS=SS所以定在同一地址空间里 
-- 
___________________ 
吃睡吃睡吃睡吃睡吃睡 
___________________ 
 
※ 修改:?suxm 於 Feb 16 18:46:06 修改本文?[FROM:   166.111.8.153] 
※ 修改:?suxm 於 Feb 16 18:52:16 修改本文?[FROM:   166.111.8.153] 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 166.111.146.241] 
发信人: wwwwww (困困), 信区: Programming 
标  题: Re: 关于VXD的问题 
发信站: BBS 水木清华站 (Mon Feb 16 18:58:51 1998) 
 
多谢大侠指点。 
小弟还有一事不明： 
如果32位应用程序与VXD在同一4GB的空间内， 
那应用程序自然可以利用指针直接存取VXD中的全局变量。 
不明白的是：那VXD可以利用指针直接存取应用程序中的 
全局变量吗？如果可以的话，那岂不乱套了？-----如果 
同时运行两份应用程序的拷贝，那VXD存取的是哪个应用程序 
中的全局变量呢？ 
 
 
【 在 suxm (笨笨) 的大作中提到: 】 
∶                 ~~~~~~~~ 
∶                的确是这样的 
∶                    ~~~~~~~~~~~~~~~~~  
∶                            是  
∶                          ~~~~~~~~~~~~~ 
∶                           2GB 
∶    每一个应用程序的前2GB空间都有一份系统VXD的拷贝。 
∶    这些拷贝映射为同一内存RAM地址。 
∶    这样说来应用程序只能占用2GB-----4GB之间的地址空间了。 
∶             ~~~~~~~~~~~~~~~~ 
      
 
∶             cs=ds=ss，在flat mode下请忘记段的概念，虽然CPU 
∶             仍在防护情况下使用着段 
∶                    ~~~~~~~~~~~~~~~~~ 
∶                   因为CS=DS=SS所以定在同一地址空间里 
 
 
-- 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 166.111.8.153] 
发信人: wwj (红尘一笑), 信区: Programming 
标  题: Re: 关于VXD的问题 
发信站: BBS 水木清华站 (Tue Feb 17 08:49:02 1998) 
 
【 在 wwwwww (困困) 的大作中提到: 】 
 
   Win95的Win32部分并不是以段管理为主的,它所有的虚地址及其保护特性 
基本上都是用页管理来完成. 
 
∶ 如果32位应用程序与VXD在同一4GB的空间内， 
∶ 那应用程序自然可以利用指针直接存取VXD中的全局变量。 
 
VXD所在的虚地址在每个VM中都是一样的.但从操作系统的角度说,这片区域应 
该不让应用程序可以读写到.Win95设计上出于效率和某些方面的考虑,这些区 
域可以从应用程序级读到,甚至某些地方还可以被应用程序写. 
 
∶ 不明白的是：那VXD可以利用指针直接存取应用程序中的 
∶ 全局变量吗？如果可以的话，那岂不乱套了？-----如果 
∶ 同时运行两份应用程序的拷贝，那VXD存取的是哪个应用程序 
∶ 中的全局变量呢？ 
 
从VXD的角度看来,低2G的空间是应用程序相关的.也就是说,当CPU运行 
到VXD的某段代码时,VXD所看到的低2G的空间是这个VM印象,并不能指定是哪 
个应用的;究竟是哪个应用,VXD应该进行ProcessID的判断.在原则上,操作系统 
是能读写应用的数据的. 
 
-- 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 166.111.8.123] 
发信人: holly (holly), 信区: Programming 
标  题: Re: 关于VXD的问题 
发信站: BBS 水木清华站 (Tue Feb 17 11:20:06 1998) 
 
【 在 wwj (红尘一笑) 的大作中提到: 】 
∶    Win95的Win32部分并不是以段管理为主的,它所有的虚地址及其保护特性 
∶ 基本上都是用页管理来完成. 
∶ VXD所在的虚地址在每个VM中都是一样的.但从操作系统的角度说,这片区域应 
∶ 该不让应用程序可以读写到.Win95设计上出于效率和某些方面的考虑,这些区 
∶ 域可以从应用程序级读到,甚至某些地方还可以被应用程序写. 
 
... No. Vxd Running on ring 0 and Apps running on Ring 3 
 
 
∶ 从VXD的角度看来,低2G的空间是应用程序相关的.也就是说,当CPU运行 
∶ 到VXD的某段代码时,VXD所看到的低2G的空间是这个VM印象,并不能指定是哪 
∶ 个应用的;究竟是哪个应用,VXD应该进行ProcessID的判断.在原则上,操作系统 
∶ 是能读写应用的数据的. 
 
 
-- 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 202.120.26.243] 
发信人: suxm (笨笨), 信区: Programming 
标  题: Re: 关于VXD的问题 
发信站: BBS 水木清华站 (Tue Feb 17 12:50:38 1998) 
 
 
Memory allocated in a VxD is globally,and can be shared with  
applications.Memory that an application allocates may be in a 
process specific region of the memory map.In this case,the VxD 
cannot access that memory unless the current memory context is  
that of the process.  
 
 
 
【 在 wwwwww (困困) 的大作中提到: 】 
∶ 多谢大侠指点。 
∶ 小弟还有一事不明： 
∶ 如果32位应用程序与VXD在同一4GB的空间内， 
∶ 那应用程序自然可以利用指针直接存取VXD中的全局变量。 
∶ 不明白的是：那VXD可以利用指针直接存取应用程序中的 
∶ 全局变量吗？如果可以的话，那岂不乱套了？-----如果 
∶ 同时运行两份应用程序的拷贝，那VXD存取的是哪个应用程序 
∶ 中的全局变量呢？ 
 
 
-- 
___________________ 
吃睡吃睡吃睡吃睡吃睡 
___________________ 
 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 166.111.8.142] 
发信人: suxm (笨笨), 信区: Programming 
标  题: Re: 关于VXD的问题 
发信站: BBS 水木清华站 (Tue Feb 17 12:51:55 1998) 
 
No.Can. 
See the examples of the win95 ddk. 
 
 
 
【 在 holly (holly) 的大作中提到: 】 
∶ ... No. Vxd Running on ring 0 and Apps running on Ring 3 
 
 
-- 
___________________ 
吃睡吃睡吃睡吃睡吃睡 
___________________ 
 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 166.111.8.142] 
发信人: Dreammy (这个杀手不太冷), 信区: Programming 
标  题: Re: 关于VXD的问题 
发信站: BBS 水木清华站 (Tue Feb 24 09:01:42 1998) 
 
【 在 wwwwww (困困) 的大作中提到: 】 
∶ 多谢大侠指点。 
∶ 小弟还有一事不明： 
∶ 如果32位应用程序与VXD在同一4GB的空间内， 
∶ 那应用程序自然可以利用指针直接存取VXD中的全局变量。 
∶ 不明白的是：那VXD可以利用指针直接存取应用程序中的 
∶ 全局变量吗？如果可以的话，那岂不乱套了？-----如果 
∶ 同时运行两份应用程序的拷贝，那VXD存取的是哪个应用程序 
∶ 中的全局变量呢？ 
实际上，在95和31中这个问题都可以提的，是个概念问题 
 
在95中之所以叫做FLAT无非是因为所有WIN32应用的代码段 
都是一样的，而在31下大家是同一个4GB的线性地址，所以 
从这个角度讲，是一样的 
    在31中，全局页表和局部页表是相同的，那么RING0所 
在内存区域是采用设置叶面属性的方法解决的 
    在95中 
全局页表和局部页表是不同的，@而且各WIN32应用的 
局部页表也不同 ，所以对不同进程，线性地址与物理 
地址映射不同 ， 大家在不同的线性空间里。 
 
-- 
※ 来源:?BBS 水木清华站 bbs.net.tsinghua.edu.cn?[FROM: 166.111.6.26]