Menu
▾
▴
reactos-kernel
|
From: Robert K. <ro...@ko...> - 2002-05-29 23:36:50
|
The native vs. Win32 theme again. I think David convinced me that it would be better to have basic win32-dlls as native-dlls. An architecture with sub systems tends to duplicate code. However some code is nearly made to be reused by different sub systems. If the advapi, gdi, user and winsock APIs were native, it would make my os2 developement much less work intensive. kernel is not so importand for me 'cos it implements already too much sub system (for my flavor). However having direct access to the GUI makes os2-apps in some kind indipendent from win32. A sockets lib and advapi as native prevents from implementing things over and over. WHICH DLLs become native now? consider also making one or more native-dlls and let the original win32-dlls make calls to the new. |
|
From: Casper H. <ch...@us...> - 2002-05-30 00:09:14
|
tor, 2002-05-30 kl. 01:37 skrev Robert K.: > The native vs. Win32 theme again. > > WHICH DLLs become native now? Those lower level Win32 DLLs that links directly with ntdll.dll now will become native DLLs. |
|
From: Robert K. <ro...@ko...> - 2002-05-30 18:26:42
|
So may I use these dlls for implementing so2ss. the graphics architecture is not too comon to me. Is it this way possible to draw lines and use windows as a win32 app would be able to? With other words: Has csrss.exe much to do with windowing. Casper Hornstrup schrieb: > tor, 2002-05-30 kl. 01:37 skrev Robert K.: > > The native vs. Win32 theme again. > > > > WHICH DLLs become native now? > > Those lower level Win32 DLLs that links directly with ntdll.dll now will > become native DLLs. > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Steven E. <ste...@ya...> - 2002-05-30 18:41:08
|
> So may I use these dlls for implementing so2ss. > > the graphics architecture is not too comon to me. > Is it this way possible to draw lines and use > windows as a win32 app would > be able to? > With other words: Has csrss.exe much to do with > windowing. You should be able to use GDI32 and USER32 they make the needed calls to win32k.sys for Windowing. Thanks Steven __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com |
|
From: Robert K. <ro...@ko...> - 2002-06-02 20:36:44
|
> > You should be able to use GDI32 and USER32 they make > the needed calls to win32k.sys for Windowing. OK, but who manages the actual windows or the frame windows. I made the observation that if an app blocks, the frame window still works. This matches also that windows opened by a killed app, are also wiped away. This would imply that csrss registers when an app starts and which win belongs to it, in order to be able to remove it possibly. This question may also be an answer to Yuri's complaints about "what is a ss? just a wrapper or even more". A sub system is the place where information can be stored over processes or between systemcalls. > > > Thanks > Steven > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: Casper H. <ch...@us...> - 2002-05-30 20:29:26
|
tor, 2002-05-30 kl. 20:27 skrev Robert K.: > So may I use these dlls for implementing so2ss. Yes you may, and I even recommend that you do. > the graphics architecture is not too comon to me. > Is it this way possible to draw lines and use windows as a win32 app would > be able to? Yes. If your OS/2 subsystem DLLs link with gdi32.dll you can use drawing primitives to perform drawing activities. Use user32.dll for higher level objects such as windows, menus and messages. > With other words: Has csrss.exe much to do with windowing. No. Csrss.exe handles consoles and access to the blue screen device. - Casper |
|
From: Aliberti E. <ea...@us...> - 2002-05-30 21:42:53
|
On 30 May 2002 at 22:21, Casper Hornstrup wrote: > > So may I use these dlls for implementing so2ss. > > Yes you may, and I even recommend that you do. I am quite off the ros project lately, but I want to say that I dislike this approach. > > the graphics architecture is not too comon to me. > > Is it this way possible to draw lines and use windows as a win32 app > > would be able to? > > Yes. If your OS/2 subsystem DLLs link with gdi32.dll you can use > drawing primitives to perform drawing activities. Use user32.dll for > higher level objects such as windows, menus and messages. OS/2 has its own graphics and windowing API: why should it use Win32? > > With other words: Has csrss.exe much to do with windowing. > > No. Csrss.exe handles consoles and access to the blue screen device. I propose to rename that server "w32ss.exe". It is no more a c/s run- time and our implementation is not plug-in based (=DLL based). |
|
From: Patrick M. <ox...@st...> - 2002-05-31 05:30:05
|
On Thu, May 30, 2002 at 11:44:20PM +0200, Aliberti Emanuele wrote: > OS/2 has its own graphics and windowing API: why should it use Win32? it should at least use win32 windows and messages - that way you can run win32 and os/2 stuff on one desktop. getting them on one desktop with two distinct "window lists" (or however they are stored internally) you'll have a big time trying to keep them all up-to-date... patrick mauritz -- > In the Beginning there was nothing, which exploded - Yeah right... < |
|
From: Yuri P. <pro...@fr...> - 2002-05-31 05:50:30
|
On Fri, 31 May 2002 07:28:16 +0200, Patrick Mauritz wrote: >On Thu, May 30, 2002 at 11:44:20PM +0200, Aliberti Emanuele wrote: >> OS/2 has its own graphics and windowing API: why should it use Win32? >it should at least use win32 windows and messages - that way you can >run win32 and os/2 stuff on one desktop. >getting them on one desktop with two distinct "window lists" (or however they >are stored internally) you'll have a big time trying to keep them all >up-to-date... Well. Question is _why_ should it use win32? _Why_ not win32k? Of couse, os2ss (and any other ss) can (and must) use common window manager and messages. But why make it depended on win32? I don't like this aproach. I consider usage of win32k graphics is ok, but usage of win32 graphics and highlevel objects is bad. I don't like to see win32-looks windows on my desktop. I prefer to see os2-style windows on my desktop. |
|
From: Casper H. <ch...@us...> - 2002-05-31 12:55:15
|
fre, 2002-05-31 kl. 18:50 skrev Yuri Prokushev: > On Fri, 31 May 2002 07:28:16 +0200, Patrick Mauritz wrote: > > >On Thu, May 30, 2002 at 11:44:20PM +0200, Aliberti Emanuele wrote: > >> OS/2 has its own graphics and windowing API: why should it use Win32? > >it should at least use win32 windows and messages - that way you can > >run win32 and os/2 stuff on one desktop. > >getting them on one desktop with two distinct "window lists" (or however they > >are stored internally) you'll have a big time trying to keep them all > >up-to-date... > Well. Question is _why_ should it use win32? _Why_ not win32k? Of couse, os2ss (and any other ss) can (and must) use common window manager and messages. But > why make it depended on win32? I don't like this aproach. I consider usage of win32k graphics is ok, but usage of win32 graphics and highlevel objects is bad. I don't like > to see win32-looks windows on my desktop. I prefer to see os2-style windows on my desktop. Maybe you don't like it because you still see user32.dll and gdi32.dll as Win32 components. Well that all changed when we decided to make them native. Even such a small change can make a big difference to how you percieve things. Now, these components have been adopted as _the_ standard user mode interface to the window manager and GDI and they are no more part of the Win32 subsystem than any other subsystem. They are subsystem support code. Using these DLLs in subsystems does not mean that the subsystems cannot have their own look and feel. It gives you the _option_ of not having to duplicate the user32.dll for each and every subsystem and you can then focus on getting your subsystem to do what it is supposed to do; run applications that expect certain APIs. You also have the option of reimplementing user32.dll if you feel strongly about your applications look and feel differently from others on the desktop. - Casper |
|
From: David W. <we...@cw...> - 2002-05-31 21:17:55
|
On Fri, May 31, 2002 at 02:49:05PM +0200, Casper Hornstrup wrote: > Maybe you don't like it because you still see user32.dll and gdi32.dll > as Win32 components. Well that all changed when we decided to make them > native. Even such a small change can make a big difference to how you > percieve things. Now, these components have been adopted as _the_ > standard user mode interface to the window manager and GDI and they are > no more part of the Win32 subsystem than any other subsystem. They are > subsystem support code. Using these DLLs in subsystems does not mean > that the subsystems cannot have their own look and feel. It gives you > the _option_ of not having to duplicate the user32.dll for each and > every subsystem and you can then focus on getting your subsystem to do > what it is supposed to do; run applications that expect certain APIs. > You also have the option of reimplementing user32.dll if you feel > strongly about your applications look and feel differently from others > on the desktop. > I did not realise we had decided this! In my view, user32, gdi32 and win32k.sys should implement the user and gdi parts of the Win32 API and nothing else. Of course other subsystems can use these to emulate whatever APIs they want just as they can on Windows NT itself. |
|
From: Casper H. <ch...@us...> - 2002-05-31 21:34:12
|
l=F8r, 2002-06-01 kl. 00:16 skrev David Welch: > On Fri, May 31, 2002 at 02:49:05PM +0200, Casper Hornstrup wrote: > > Maybe you don't like it because you still see user32.dll and gdi32.dll > > as Win32 components. Well that all changed when we decided to make them > > native. Even such a small change can make a big difference to how you > > percieve things. Now, these components have been adopted as _the_ > > standard user mode interface to the window manager and GDI and they are > > no more part of the Win32 subsystem than any other subsystem. They are > > subsystem support code. Using these DLLs in subsystems does not mean > > that the subsystems cannot have their own look and feel. It gives you > > the _option_ of not having to duplicate the user32.dll for each and > > every subsystem and you can then focus on getting your subsystem to do > > what it is supposed to do; run applications that expect certain APIs. > > You also have the option of reimplementing user32.dll if you feel > > strongly about your applications look and feel differently from others > > on the desktop. > >=20 > I did not realise we had decided this! In my view, user32, gdi32 and=20 > win32k.sys should implement the user and gdi parts of the Win32 API and=20 > nothing else. Of course other subsystems can use these to emulate whateve= r=20 > APIs they want just as they can on Windows NT itself. Yes, the graphics APIs of other subsystems can be written as thin wrappers to gdi32.dll and user32.dll. Since these modules perform most of the win32k.sys interfacing, the wrappers should be small compared to the subsystems using win32k.sys directly. - Casper |
|
From: Yuri P. <pro...@fr...> - 2002-06-01 05:08:55
|
On 31 May 2002 23:27:55 +0200, Casper Hornstrup wrote: >l r, 2002-06-01 kl. 00:16 skrev David Welch: >> On Fri, May 31, 2002 at 02:49:05PM +0200, Casper Hornstrup wrote: >> > Maybe you don't like it because you still see user32.dll and gdi32.dll >> > as Win32 components. Well that all changed when we decided to make them >> > native. Even such a small change can make a big difference to how you >> > percieve things. Now, these components have been adopted as _the_ >> > standard user mode interface to the window manager and GDI and they are >> > no more part of the Win32 subsystem than any other subsystem. They are >> > subsystem support code. Using these DLLs in subsystems does not mean >> > that the subsystems cannot have their own look and feel. It gives you >> > the _option_ of not having to duplicate the user32.dll for each and >> > every subsystem and you can then focus on getting your subsystem to do >> > what it is supposed to do; run applications that expect certain APIs. >> > You also have the option of reimplementing user32.dll if you feel >> > strongly about your applications look and feel differently from others >> > on the desktop. >> > >> I did not realise we had decided this! In my view, user32, gdi32 and >> win32k.sys should implement the user and gdi parts of the Win32 API and >> nothing else. Of course other subsystems can use these to emulate whatever >> APIs they want just as they can on Windows NT itself. > >Yes, the graphics APIs of other subsystems can be written as thin >wrappers to gdi32.dll and user32.dll. Since these modules perform most >of the win32k.sys interfacing, the wrappers should be small compared to >the subsystems using win32k.sys directly. Well. Now I again don't understand goal of subsystems. Why then don't use ODIN approach? Just make wrappers from pm* to *32 dlls? And how win32 apps will interact with gdi32? Or all win32 will be moved to native part? |
|
From: Casper H. <ch...@us...> - 2002-06-01 12:37:44
|
l=F8r, 2002-06-01 kl. 18:10 skrev Yuri Prokushev: > On 31 May 2002 23:27:55 +0200, Casper Hornstrup wrote: > >Yes, the graphics APIs of other subsystems can be written as thin > >wrappers to gdi32.dll and user32.dll. Since these modules perform most > >of the win32k.sys interfacing, the wrappers should be small compared to > >the subsystems using win32k.sys directly. > Well. Now I again don't understand goal of subsystems. Why then don't use= ODIN approach? Just make wrappers from pm* to *32 dlls? And how win32 apps= will interact=20 > with gdi32? That is exactly what subsystem developers have the option to do if we do as I have described earlier. Or all win32 will be moved to native part? Only lowest-level Win32 components. The rest can be shared with WINE. If done as described, then lowest level Win32 components will be tied closer to the ReactOS kernel than to the Win32 subsystem. - Casper |
|
From: KJK::Hyperion <no...@li...> - 2002-05-31 23:46:48
|
At 00.16 01/06/2002, you wrote: >On Fri, May 31, 2002 at 02:49:05PM +0200, Casper Hornstrup wrote: > > Maybe you don't like it because you still see user32.dll and gdi32.dll > > as Win32 components. Well that all changed when we decided to make them > > native. >[...] >I did not realise we had decided this! "we" didn't decide, Casper did. The others accepted for lack of better ideas, or they just don't seem to follow the discussions anymore. Speaking of myself, despite I really care for ReactOS, I chose not to comment anymore on the topic. I'm losing interest in this sort of things |
|
From: Casper H. <ch...@us...> - 2002-06-01 00:36:53
|
l=F8r, 2002-06-01 kl. 00:55 skrev KJK::Hyperion: > At 00.16 01/06/2002, you wrote: > >On Fri, May 31, 2002 at 02:49:05PM +0200, Casper Hornstrup wrote: > > > Maybe you don't like it because you still see user32.dll and gdi32.dl= l > > > as Win32 components. Well that all changed when we decided to make th= em > > > native. > >[...] > >I did not realise we had decided this! >=20 > "we" didn't decide, Casper did. The others accepted for lack of better=20 > ideas, or they just don't seem to follow the discussions anymore. Speakin= g=20 > of myself, despite I really care for ReactOS, I chose not to comment=20 > anymore on the topic. I'm losing interest in this sort of things Maybe it was a mistake to assume that this discussion was over, but there has not been any messages in the thread "Fwd: Reorganizing the cvs repository before starting reactos.org" where someone argued against this for two weeks. I would have provided some links to the list archieve, but the sourceforge list archieve is screwed up. I initally wanted to seperate subsystems to their own CVS modules and have subsystems not depend on each other (ie. put the Win32 subsystem in it's own module too just like all other subsystems). David then said that Win32 was inseperable from the ReactOS kernel and that the Win32 subsystem should stay in the reactos module. I did not like the idea of having modules marked win32 only in the required reactos module, so I suggested that we make these "inseperable" Win32 modules native so they don't belong to a specific subsystem and can thus optionally be used in any subsystem that needs the functionality they provide. Then I was okay with putting them in the reactos module. David agreed to this compomize and nobody else has argued against this for about two weeks now. So please present your arguments if you have some; so we can take vote or something. - Casper |
|
From: Nick D. <nic...@ya...> - 2002-05-31 10:37:20
|
Hi Patrick, ----- Original Message ----- From: "Patrick Mauritz" <ox...@st...> To: <rea...@li...> Sent: Friday, May 31, 2002 6:28 AM Subject: Re: [ros-kernel] native vs. Win32 - again > On Thu, May 30, 2002 at 11:44:20PM +0200, Aliberti Emanuele wrote: > > OS/2 has its own graphics and windowing API: why should it use Win32? > it should at least use win32 windows and messages - that way you can > run win32 and os/2 stuff on one desktop. > getting them on one desktop with two distinct "window lists" (or however they > are stored internally) you'll have a big time trying to keep them all > up-to-date... I see where you're coming from here. I'm wondering how much of win32 it would be feasable to strip from ReactOS if the user only wants to run OS/2 apps (save some space on your 40 gig hard disk :-] ). It seems to me that in order to do this you'd have to go back to the kernel and write an OS/2 GDI/GUI, but wouldn't this be a seperate project from OS/2 binary compatibility? I have that Linux thingy that lets you run apps (recompiled to PE standard) in one common interface. I think this is fine for the odd app that no one would really want to port to the win32 GUI but it is slow and has problems. Regards, Nick. -- Nick Date Bath, England, UK --- Outgoing mail is certified virus free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.365 / Virus Database: 202 - Release Date: 24/05/2002 _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
|
From: Yuri P. <pro...@fr...> - 2002-05-31 11:44:25
|
On Fri, 31 May 2002 11:36:50 +0100, Nick Date wrote: >> > OS/2 has its own graphics and windowing API: why should it use Win32? > >> it should at least use win32 windows and messages - that way you can >> run win32 and os/2 stuff on one desktop. >> getting them on one desktop with two distinct "window lists" (or however >they >> are stored internally) you'll have a big time trying to keep them all >> up-to-date... >I see where you're coming from here. I'm wondering how much of win32 it >would be feasable to strip from ReactOS if the user only wants to run OS/2 >apps (save some space on your 40 gig hard disk :-] ). Why I need storage space for unused things? > It seems to me that in >order to do this you'd have to go back to the kernel and write an OS/2 >GDI/GUI, but wouldn't this be a seperate project from OS/2 binary >compatibility? Who needs binary compatibility without APIs? GDI implemented by win32k. Isn't it? So all OS/2 GPI (=GDI) can be easely implemented like gdi32.dll (pmgpi in os2). Highlevel objects (user32.dll in win32) can be just copied (for common object like editfield). For other controls (like spinbuttons) code must be written from the scratch. So I don't see any reason for implement pmgpi via gdi32 instead of direct implementation via win32k. |
|
From: Robert K. <ro...@ko...> - 2002-06-02 20:39:02
|
My intend is to use just the naked windows from USer32. Other things like controls need a reimplementation since they use different window messages. this implies that the controls may look as one likes. Yuri Prokushev schrieb: > On Fri, 31 May 2002 11:36:50 +0100, Nick Date wrote: > > >> > OS/2 has its own graphics and windowing API: why should it use Win32? > > > >> it should at least use win32 windows and messages - that way you can > >> run win32 and os/2 stuff on one desktop. > >> getting them on one desktop with two distinct "window lists" (or however > >they > >> are stored internally) you'll have a big time trying to keep them all > >> up-to-date... > >I see where you're coming from here. I'm wondering how much of win32 it > >would be feasable to strip from ReactOS if the user only wants to run OS/2 > >apps (save some space on your 40 gig hard disk :-] ). > Why I need storage space for unused things? > > > It seems to me that in > >order to do this you'd have to go back to the kernel and write an OS/2 > >GDI/GUI, but wouldn't this be a seperate project from OS/2 binary > >compatibility? > Who needs binary compatibility without APIs? > > GDI implemented by win32k. Isn't it? So all OS/2 GPI (=GDI) can be easely implemented like gdi32.dll (pmgpi in os2). Highlevel objects (user32.dll in win32) can be just > copied (for common object like editfield). For other controls (like spinbuttons) code must be written from the scratch. So I don't see any reason for implement pmgpi via > gdi32 instead of direct implementation via win32k. > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > reactos-kernel mailing list > rea...@li... > https://lists.sourceforge.net/lists/listinfo/reactos-kernel |
|
From: KJK::Hyperion <no...@li...> - 2002-05-31 20:28:51
|
At 23.44 30/05/2002, you wrote: > > > With other words: Has csrss.exe much to do with windowing. > > No. Csrss.exe handles consoles and access to the blue screen device. >I propose to rename that server "w32ss.exe". It is no more a c/s run-time >and our implementation is not plug-in based (=DLL based). Emanuele, but I liked the plugin-based approach. Don't you think it's better? especially when several subsystems are installed at once? |
