Menu
▾
▴
reactos-kernel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(64) |
Oct
(438) |
Nov
(183) |
Dec
|
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(132) |
May
(466) |
Jun
(366) |
Jul
(392) |
Aug
(31) |
Sep
(18) |
Oct
|
Nov
|
Dec
|
|
From: Jason F. <jas...@ya...> - 2001-11-13 08:56:17
|
Ok.. well then how does a CreateCompatibleDC(NULL) know what the current application's DC is? It somehow has to figure out which is the active window of the active desktop... if there are multiple active windows in multiple active desktops... well, how? - Jason --- Phillip Susi <ps...@cf...> wrote: > I don't see why you can't have multiple interactive desktops if you > have > multiple monitors and keyboards/mice, but even non interactive > desktops > still need to maintain the active window so that when you switch to > that > desktop, it remembers what the active window was. > > At 11:12 PM 11/12/2001 +0100, you wrote: > >On Monday 12 November 2001 21:05, Jason Filby wrote: > > > Is there just one foreground window in the entire system (a > global > > > variable)? Or does each desktop (or perhaps each workstation) > have a > > > foreground window? > > > >There is one input desktop per interactive window station. And > there is > >only one interactive windowstation (maybe more if terminal > services is > >installed). I do not think it makes sense to have a foreground > window on > >non-interactive desktops. > > > > Casper > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > __________________________________________________ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert D. <od...@pn...> - 2001-11-13 08:10:59
|
I've got some guinea-pig (or should that be lab-rat) machines I can use, just need instructions on what change is required and i'll report back..... Rgs, Robert Dickenson. At 01:27 AM 13/11/2001 +0100, you wrote: >At 21.27 11/11/2001 +0100, you wrote: >>Overcoming User32.dll Initialization Failure Errors: >>http://support.microsoft.com/support/kb/articles/Q126/9/62.asp > >Has anyone had the guts to change that Windows=On in the csrss.exe command >line into a Windows=Off to see what happens? And what about that >SubSystemType=Windows? > ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: KJK::Hyperion <no...@li...> - 2001-11-13 07:23:42
|
At 13.40 12/11/2001 -0500, you wrote: >Anyway, you *might* be able to strip Vim down enough so that it doesn't >need these DLLs. A lot of these features are not strictly necessary. I got an old Vi clone port lying around, found it in the Windows 98 Resource Kit. It should be stripped down enough ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: KJK::Hyperion <no...@li...> - 2001-11-13 07:21:17
|
At 15.00 11/11/2001 -0500, you wrote: >Filesystems are ext2. fat16. fat32. minix ext2 works for real? can I, let's see, steal the ext2 driver from ReactOS for use in NT? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: KJK::Hyperion <no...@li...> - 2001-11-13 07:20:32
|
At 21.27 11/11/2001 +0100, you wrote: >Overcoming User32.dll Initialization Failure Errors: >http://support.microsoft.com/support/kb/articles/Q126/9/62.asp Has anyone had the guts to change that Windows=On in the csrss.exe command line into a Windows=Off to see what happens? And what about that SubSystemType=Windows? ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-13 02:56:44
|
Yes, if the image is marked as gui, it does not inherit access to the parrent's console. If it is marked as cui, then it gets a new console if run from a gui app, which is a pita for apps that want to have an optional gui, but also be runnable from the command line. At 12:11 PM 11/13/2001 +1100, you wrote: >I thought a GUI app was _not_ passed the console handle when it's >started from cmd.exe (or an equivalent). > >Thats more than a compiler difference IMO. > >If however, this is a compiler issue, please please please let me know >what call is in the prolog to get attach to the console - the only >AttachConsole call I know of is in XP, and the behaviour of not getting >the console handle has existed since win95. > > >Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Robert C. <rob...@it...> - 2001-11-13 01:43:01
|
> -----Original Message----- > From: Craig Barkhouse > To: ros...@re... > Sent: 11/12/01 1:40 PM > Subject: [ros-kernel] Re: Bug Report - VIM for Win32 > > There is no fundamental difference between a console app and a GUI app. > The difference is mainly what the compiler inserts into your program as > startup code. Once running, both types of apps have FULL access to the > Win32 API. A console app can suddenly open up windows and dialog boxes; > a GUI app can suddenly launch a console session. You get the idea. I thought a GUI app was _not_ passed the console handle when it's started from cmd.exe (or an equivalent). Thats more than a compiler difference IMO. If however, this is a compiler issue, please please please let me know what call is in the prolog to get attach to the console - the only AttachConsole call I know of is in XP, and the behaviour of not getting the console handle has existed since win95. Rob ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Steven E. <Ste...@kn...> - 2001-11-13 01:07:37
|
I'm going to try to build a striped vim for reactos based off of vim 6.0 in the next week or so. Steven -----Original Message----- From: Craig Barkhouse To: ros...@re... Sent: 11/12/01 1:40 PM Subject: [ros-kernel] Re: Bug Report - VIM for Win32 There is no fundamental difference between a console app and a GUI app. The difference is mainly what the compiler inserts into your program as startup code. Once running, both types of apps have FULL access to the Win32 API. A console app can suddenly open up windows and dialog boxes; a GUI app can suddenly launch a console session. You get the idea. In addition to window-related functions, User32.dll also has lots of functions for messages, events, processes, and threads. Vim uses User32.dll for FindWindow() (an attempt to get the console window handle, for the purpose of changing the icon (see below)), MsgWaitForMultipleObjects() (for interprocess message passing), and possibly other stuff. Vim uses Shell32.dll for ExtractIcon() (it changes the icon of the console window while it is running) and possibly other stuff. I don't know why Vim needs Comctl32.dll. I wonder if this really was a console build rather than a GUI build. When I build console Vim, it doesn't appear to link with Comctl32.dll. Anyway, you *might* be able to strip Vim down enough so that it doesn't need these DLLs. A lot of these features are not strictly necessary. ----- Original Message ----- From: "Phillip Susi" <ps...@cf...> To: <ros...@re...> Sent: Sunday, November 11, 2001 3:54 PM Subject: [ros-kernel] Re: Bug Report - VIM for Win32 > Isn't vim console based? Then why the heck is it importing things from > user32, comctl32, and shell32? > > At 03:40 PM 11/11/2001 -0500, you wrote: > > >vim.exe crashes because it cant import GetSysColotPen which is a export of > >user32. This is what happens when i try to run vim.exe for win32 ==================================================== To remove yourself from this mailing list, go to = http://www.reactos.com/home/mailing.html =================================================== ########################################### This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. For more information, connect to http://www.F-Secure.com/ |
|
From: Phillip S. <ps...@cf...> - 2001-11-12 23:14:24
|
I don't see why you can't have multiple interactive desktops if you have multiple monitors and keyboards/mice, but even non interactive desktops still need to maintain the active window so that when you switch to that desktop, it remembers what the active window was. At 11:12 PM 11/12/2001 +0100, you wrote: >On Monday 12 November 2001 21:05, Jason Filby wrote: > > Is there just one foreground window in the entire system (a global > > variable)? Or does each desktop (or perhaps each workstation) have a > > foreground window? > >There is one input desktop per interactive window station. And there is >only one interactive windowstation (maybe more if terminal services is >installed). I do not think it makes sense to have a foreground window on >non-interactive desktops. > > Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-12 23:03:22
|
That's what dos is for. loadros uses dos int 21 to load the files. It could simply load freeldr.sys to the correct location in memory, and jump to it. At 01:25 PM 11/12/2001 -0800, you wrote: >--- Phillip Susi <ps...@cf...> wrote: > >You could boot freeldr from a floppy disk, that way without the > >floppy, you boot dos, insert floppy, and freeloader boots reactos. > >Slow.. I'd rather have loadros stick around. > > >if loadros were rewritten to chain load freeldr, I think it would > >only take about 100 lines of asm, if that. Writing it in C would > >then require a dos C compiler. > >If its going to find it, it needs to understand the filesystem.. > >- Jason > > > > > > > >__________________________________________________ >Do You Yahoo!? >Find a job, post your resume. >http://careers.yahoo.com > >==================================================== >= To remove yourself from this mailing list, go to = >= http://www.reactos.com/home/mailing.html = >==================================================== ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Swartz, J. <JS...@li...> - 2001-11-12 22:34:44
|
Forgive me if I am out of place. I've been signed on to the lists for a few weeks now and though I have not had the courage to participate yet, I do feel I can comment on this particular question. > Is there just one foreground window in the entire system (a global > variable)? Definitely no. > Or does each desktop (or perhaps each workstation) have a foreground > window? Assuming we have the same definition of desktop and workstation, then yes. Remember that Windows servers can be extended in this regard so the underlying architecture does not limit the entire system to just one foreground window. I think your use of the term "workstation" equates to Microsoft's use of the term "window station." On Windows Terminal Server, there can be multiple users each with a foreground window. Older solutions like Citrix/WinFrame/MetaFrame also behaved similarly -- they did it with their own versions of User32, Kernel32, etc. though. There's an article in MSSJ, Dec. 1998 (saw it in the April 2001 DevNet) that gives the basics -- including a bit about the sequence of events for login which has been discussed on your list recently. It seems I read something somewhere that was much more detailed but unfortunately I cannot find it right now. To further complicate things, I know that there is the concept of "hidden" desktops. This would apply to things like a service for example. I'm not sure that these would have a "foreground window" or not -- I suspect the facilities would exist but wouldn't be used. I say this because a service can be set to interact with the desktop. If this is done, it interacts just like all the user spawned processes and there'd be only one foreground window among them. (I hope that last bit makes sense. My overall point is that there is probably a variable per "window station" somewhere that represents the foreground window. Furthermore a system should be capable of handling multiple "window stations.") That's all I have for now. I enjoy reading about ReactOS. Jerry -----Original Message----- From: Jason Filby [mailto:jas...@ya...] Sent: Monday, November 12, 2001 12:05 PM To: ros...@re... Subject: [ros-kernel] Determining the current window Is there just one foreground window in the entire system (a global variable)? Or does each desktop (or perhaps each workstation) have a foreground window? Thanks - Jason __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-12 22:07:05
|
--- Phillip Susi <ps...@cf...> wrote: >You could boot freeldr from a floppy disk, that way without the >floppy, you boot dos, insert floppy, and freeloader boots reactos. Slow.. I'd rather have loadros stick around. >if loadros were rewritten to chain load freeldr, I think it would >only take about 100 lines of asm, if that. Writing it in C would >then require a dos C compiler. If its going to find it, it needs to understand the filesystem.. - Jason __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Casper H. <ch...@us...> - 2001-11-12 21:56:55
|
On Monday 12 November 2001 21:05, Jason Filby wrote: > Is there just one foreground window in the entire system (a global > variable)? Or does each desktop (or perhaps each workstation) have a > foreground window? There is one input desktop per interactive window station. And there is only one interactive windowstation (maybe more if terminal services is installed). I do not think it makes sense to have a foreground window on non-interactive desktops. Casper ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Brian P. <br...@sg...> - 2001-11-12 21:11:12
|
Eric is correct, it switches between real and protected mode for every BIOS call. The reason for this is so that I don't have play with GDT & IDT tables. Even so the point is that it still requires a mode switch for every call and thats what Eric is trying to eliminate. Brian -----Original Message----- From: Phillip Susi [mailto:ps...@cf...] Sent: Monday, November 12, 2001 12:28 PM To: ros...@re... Subject: [ros-kernel] Re: Thoughts about loadros Why does it have to keep switching back to real mode? Can't 16bit code be called from pmode by making an intersegment call to a 16bit code segment? I thought that's how windows worked before 386 enhanced mode: real mode code was directly called from pmode, but the code only generated references to the first 1 MB of memory, which was the same for all tasks so multiple dos VM's couldn't be run. Then 386 enhanced mode made use of virtual 86 mode to support multiple dos VM's. Also, doesn't flat real mode mean the code is running in a 16bit segment, but can still use 32bit overrides to generate 32bit addresses? Doesn't that require a special compiler or hand asm coding to do? At 11:21 AM 11/12/2001 +0100, you wrote: >You're right, the existing loadros is a hack. But OTOH, FreeLoader is not >that much better. For each bios call FreeLoader must switch to real mode and >back to protected mode while a modified loadros runs in flat real mode, this >means it can call into the bios without mode switching and can access the >full 4GB physical memory space. > >AFAIR, the main problem with FreeLoader was the 32bit disk access. IMHO it >is extremely bad to call these bios functions from protected mode. It is not >only the mode-switching but especially the fact that all parameters have to >be passed to the bios in a buffer. Brrr.. :-/ > >- Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-12 21:01:03
|
You could boot freeldr from a floppy disk, that way without the floppy, you boot dos, insert floppy, and freeloader boots reactos. If loadros were rewritten to chain load freeldr, I think it would only take about 100 lines of asm, if that. Writing it in C would then require a dos C compiler. At 11:30 AM 11/12/2001 -0800, you wrote: >Well I don't really want to play around with the boot sector of my >primary hard drive.. even if I do it, I'm sure those that just want >to try out ReactOS won't want to. I like the idea of loadros chain >loading freeldr, but wouldn't it be easier to rewrite loadros in C >then? > >- Jason ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-12 20:54:53
|
Is there just one foreground window in the entire system (a global variable)? Or does each desktop (or perhaps each workstation) have a foreground window? Thanks - Jason __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-12 20:51:19
|
Each desktop has a foreground window, and each windowstation has an active desktop. In fact, I think more than one desktop on a windowstation can be active if you have multiple displays. Each thread has a current desktop associated with it, which could be stored in the win32 specific extension block pointed to by the ETHREAD. At 12:05 PM 11/12/2001 -0800, you wrote: >Is there just one foreground window in the entire system (a global >variable)? Or does each desktop (or perhaps each workstation) have a >foreground window? > >Thanks >- Jason ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Brian P. <br...@sg...> - 2001-11-12 20:29:02
|
While switching to and from protected/real modes to make BIOS calls is certainly slower, I don't think I would trade it for flat real mode. What if inside one of the BIOS calls it decides to reload a selector for you? This would most likely not be a problem for the most basic disk i/o stuff but the system memory map calls and extended disk i/o I would beware. Besides, short of writing my own protected mode disk driver for FreeLoader there is no other alternative than switching back to real mode and calling the BIOS. Plus you would have to use low memory buffers for your disk reads in flat real mode also, the BIOS doesn't accept 32-bit buffer addresses unless you are using LBA calls. Brian -----Original Message----- From: Eric Kohl [mailto:ek...@rz...] Sent: Monday, November 12, 2001 3:21 AM To: ros...@re... Subject: [ros-kernel] Re: RE: Thoughts about loadros "Brian Palmer" <br...@sg...> wrote: > As of version 11.0c, Watcom C/C++ is going to be open source. > www.openwatcom.org AFAICS it is only an update yet. The full version is not available. And it is huuuuge, the update is more than 45MB. :-/ > Although it would be useful for loadros to support the registry, and being > able to boot from DOS is handy, I don't think that turning it into a full > boot loader would be worthwhile. There is too much that would need to be > added that is already there in FreeLoader. To me loadros has always seemed > like a hack that needs to be put out to pasture. You're right, the existing loadros is a hack. But OTOH, FreeLoader is not that much better. For each bios call FreeLoader must switch to real mode and back to protected mode while a modified loadros runs in flat real mode, this means it can call into the bios without mode switching and can access the full 4GB physical memory space. AFAIR, the main problem with FreeLoader was the 32bit disk access. IMHO it is extremely bad to call these bios functions from protected mode. It is not only the mode-switching but especially the fact that all parameters have to be passed to the bios in a buffer. Brrr.. :-/ - Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-12 20:07:51
|
AFAIK, all desktops are created by winlogon on the interactive windowstation which is also created by winlogon. The part that win32k creates is the desktop _window_. At 11:27 AM 11/12/2001 -0800, you wrote: > >From the desktop messages (which I'm finally catching up with) it >seems that the application desktop is created by win32k? The others, >winlogon and screensaver can be created by winlogon? Then again, >what's wrong with creating the application desktop in winlogon as >well? > >- Jason ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-12 20:02:12
|
Why does it have to keep switching back to real mode? Can't 16bit code be called from pmode by making an intersegment call to a 16bit code segment? I thought that's how windows worked before 386 enhanced mode: real mode code was directly called from pmode, but the code only generated references to the first 1 MB of memory, which was the same for all tasks so multiple dos VM's couldn't be run. Then 386 enhanced mode made use of virtual 86 mode to support multiple dos VM's. Also, doesn't flat real mode mean the code is running in a 16bit segment, but can still use 32bit overrides to generate 32bit addresses? Doesn't that require a special compiler or hand asm coding to do? At 11:21 AM 11/12/2001 +0100, you wrote: >You're right, the existing loadros is a hack. But OTOH, FreeLoader is not >that much better. For each bios call FreeLoader must switch to real mode and >back to protected mode while a modified loadros runs in flat real mode, this >means it can call into the bios without mode switching and can access the >full 4GB physical memory space. > >AFAIR, the main problem with FreeLoader was the 32bit disk access. IMHO it >is extremely bad to call these bios functions from protected mode. It is not >only the mode-switching but especially the fact that all parameters have to >be passed to the bios in a buffer. Brrr.. :-/ > >- Eric Kohl ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-12 19:58:13
|
Well I don't really want to play around with the boot sector of my primary hard drive.. even if I do it, I'm sure those that just want to try out ReactOS won't want to. I like the idea of loadros chain loading freeldr, but wouldn't it be easier to rewrite loadros in C then? - Jason --- Phillip Susi <ps...@cf...> wrote: > Why can't you use freeldr? Also, to support loading from dos ( > though I > can't see why you can't just reboot to freeldr and choose reactos > ), maybe > loadros could be rewritten to chain load freeldr as if it had been > loaded > by the bios, and let it do the rest of the work? > > At 01:37 AM 11/12/2001 -0800, you wrote: > >--- Brian Palmer <br...@sg...> wrote: > > > > >As of version 11.0c, Watcom C/C++ is going to be open source. > > >www.openwatcom.org > > > >This looks good! > > > > >To me loadros has always seemed like a hack that needs to be put > out > > >to pasture. > > > >But its the only way I can test ros on real hardware! > > > >- Jason > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-12 19:51:16
|
>From the desktop messages (which I'm finally catching up with) it seems that the application desktop is created by win32k? The others, winlogon and screensaver can be created by winlogon? Then again, what's wrong with creating the application desktop in winlogon as well? - Jason __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Phillip S. <ps...@cf...> - 2001-11-12 19:29:39
|
Why can't you use freeldr? Also, to support loading from dos ( though I can't see why you can't just reboot to freeldr and choose reactos ), maybe loadros could be rewritten to chain load freeldr as if it had been loaded by the bios, and let it do the rest of the work? At 01:37 AM 11/12/2001 -0800, you wrote: >--- Brian Palmer <br...@sg...> wrote: > > >As of version 11.0c, Watcom C/C++ is going to be open source. > >www.openwatcom.org > >This looks good! > > >To me loadros has always seemed like a hack that needs to be put out > >to pasture. > >But its the only way I can test ros on real hardware! > >- Jason ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Jason F. <jas...@ya...> - 2001-11-12 19:01:18
|
Couldn't find zeiss.de subscribed.. I take it someone else got to this? --- Phillip Susi <ps...@cf...> wrote: > Could someone remove this guy from the mailing list? I'm getting > tired of > all of these bounced messages. > > > >Conversion: Allowed > >Original-Encoded-Information-Types: IA5-Text > >Priority: normal > >Disclose-Recipients: Prohibited > >Alternate-Recipient: Allowed > >Date: 12 Nov 2001 01:23:12 +0100 > >From: Mailer-Daemon <Mai...@ze...> > >To: psusi <ps...@cf...> > >Subject: Undeliverable Mail > > > >------------------------- Could not deliver Message to > >------------------------- > > CN=Heiko > Ronsdorf/OU=DEMAI/O=Schott@SCHOTT > > > >Router: Unable to open mailbox file SDEJENS2000/SERVER/SCHOTT > mail.box: > >Server not responding > > > >----------------------------- Your Original Message > >---------------------------- > > > >Date: 11/11/2001 01:12 AM > >From: ps...@cf...@Internet > >Subject: [ros-general] Re: GUI commision > >Priority: Normal > >Importance: 2 > >Nice... how is that going? I was thinking of trying to get emacs > to work. > > > >At 06:13 PM 11/10/2001 -0500, you wrote: > > > > >As for the text mode stuff I've been working on getting vi and > mc to work > > >under reactos. > > > >==================================================== > >= To remove yourself from this mailing list, go to = > >= http://www.reactos.com/home/mailing.html = > >==================================================== > > ==================================================== > = To remove yourself from this mailing list, go to = > = http://www.reactos.com/home/mailing.html = > ==================================================== > __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
|
From: Craig B. <cr...@wa...> - 2001-11-12 18:43:54
|
There is no fundamental difference between a console app and a GUI app. = The difference is mainly what the compiler inserts into your program as = startup code. Once running, both types of apps have FULL access to the = Win32 API. A console app can suddenly open up windows and dialog boxes; = a GUI app can suddenly launch a console session. You get the idea. In addition to window-related functions, User32.dll also has lots of = functions for messages, events, processes, and threads. Vim uses = User32.dll for FindWindow() (an attempt to get the console window = handle, for the purpose of changing the icon (see below)), = MsgWaitForMultipleObjects() (for interprocess message passing), and = possibly other stuff. Vim uses Shell32.dll for ExtractIcon() (it changes the icon of the = console window while it is running) and possibly other stuff. I don't know why Vim needs Comctl32.dll. I wonder if this really was a = console build rather than a GUI build. When I build console Vim, it = doesn't appear to link with Comctl32.dll. Anyway, you *might* be able to strip Vim down enough so that it doesn't = need these DLLs. A lot of these features are not strictly necessary. ----- Original Message -----=20 From: "Phillip Susi" <ps...@cf...> To: <ros...@re...> Sent: Sunday, November 11, 2001 3:54 PM Subject: [ros-kernel] Re: Bug Report - VIM for Win32 > Isn't vim console based? Then why the heck is it importing things = from=20 > user32, comctl32, and shell32? >=20 > At 03:40 PM 11/11/2001 -0500, you wrote: >=20 > >vim.exe crashes because it cant import GetSysColotPen which is a = export of=20 > >user32. This is what happens when i try to run vim.exe for win32 ==================================================== = To remove yourself from this mailing list, go to = = http://www.reactos.com/home/mailing.html = ==================================================== |
8 messages has been excluded from this view by a project administrator.
