- Ros-dev - ReactOS.org

Re: [ros-svn] [ea] 18050: Required for binary compatibility with MS KERNEL32.DLL.
by KJKHyperion 25 Sep '05

25 Sep '05

ea(a)svn.reactos.com wrote: >Required for binary compatibility with MS KERNEL32.DLL. > >NOTE >Filip and I still don't understand why KERNEL32 calls twice CsrConnectToServer. >A possible explanation is because the Win32 server is a dual server: gui+console. > > yes. It connects to subsystems 1 and 2. In general, all CSR calls made by kernel32.dll are easily identifiable as calls to either subsystem from their code (the subsystem code is in the upper 16 bits). The GUI subsystem's functions, if you were wondering, are: SrvExitWindowsEx SrvEndTask SrvLogon SrvRegisterServicesProcess SrvActivateDebugger SrvGetThreadConsoleDesktop SrvDeviceEvent SrvRegisterLogonProcess SrvCreateSystemThreads SrvRecordShutdownReason

3 2

Re: [ros-svn] [ea] 18050: Required for binary compatibility with MS KERNEL32.DLL.
by Alex Ionescu 25 Sep '05

25 Sep '05

ea(a)svn.reactos.com wrote: >Required for binary compatibility with MS KERNEL32.DLL. > > > I don't understand this change; it is incorrect. MS kernel32.dll sends the name of the port. Best regards, Alex Ionescu

2 2

Re: [ros-svn] [ea] 18050: Required for binary compatibility with MS KERNEL32.DLL.
by Alex Ionescu 25 Sep '05

25 Sep '05

ea(a)svn.reactos.com wrote: >Required for binary compatibility with MS KERNEL32.DLL. > >NOTE >Filip and I still don't understand why KERNEL32 calls twice CsrConnectToServer. > Once to connect to the Base Server, and once to connect to the Console server. Best regards, Alex Ionescu

1 0

Re: [ros-diffs] [navaraf] 18043: Add TestAlert check to NtContinue.
by Hartmut Birr 25 Sep '05

25 Sep '05

navaraf(a)svn.reactos.com wrote: >Add TestAlert check to NtContinue. > >Modified: trunk/reactos/ntoskrnl/ps/i386/continue.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/ps/i386/continue.c* > >--- trunk/reactos/ntoskrnl/ps/i386/continue.c 2005-09-25 09:22:22 UTC (rev 18042) >+++ trunk/reactos/ntoskrnl/ps/i386/continue.c 2005-09-25 09:23:05 UTC (rev 18043) >@@ -80,6 +80,11 @@ > > KeLowerIrql(oldIrql); > } > > > >+ if (TestAlert) >+ { >+ KeTestAlertThread(TrapFrame->PreviousMode); >+ } >+ > > > /* Restore the user context */ > Thread->TrapFrame = PrevTrapFrame; > __asm__("mov %%ebx, %%esp;\n" "jmp _KiServiceExit": : "b" (TrapFrame)); > > You know, that ps\i386\continue.c is not longer used. The code was moved to ke\i386\syscall.S. - Hartmut

2 1

RE: [ros-dev] Priorities
by Murphy, Ged (Bolton) 24 Sep '05

24 Sep '05

I plan to implement these in the near future ..... unless someone else does it first. I currently have reworked code for tracert, arp, netstat, ipconfig, pathping and route I will start to commit over the next few weeks. I then plan to implement other services and apps in relation to networking, including test apps. Ged. -----Original Message----- From: WaxDragon [mailto:waxdragon@gmail.com] Sent: 24 September 2005 06:25 To: ReactOS Development List Subject: Re: [ros-dev] Priorities I'm would be very interested in a set of network "simple services" like echo, chargen, daytime, etc.. Having those on the install would help ReactOS get some wider network testing. WD On 9/23/05, Rick Langschultz <rlangschultz(a)cox.net> wrote: > I was wondering if there was a priority list for the next release. > Whether it be 0.2.8 or 0.3.0 I would either like to work on > implementing services and/or tcp/ip based networking. Primarily > though, getting services up and running would be great for me who > develops services. > Rick Langschultz > rlangschultz(a)cox.net (Home) > rlangschultz(a)ellemaespa.com (Work) > rlangschultz(a)email.uophx.edu (School) > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev > -- <arty> don't question it ... it's clearly an optimization _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

1 0

Priorities
by Rick Langschultz 24 Sep '05

24 Sep '05

I was wondering if there was a priority list for the next release. Whether it be 0.2.8 or 0.3.0 I would either like to work on implementing services and/or tcp/ip based networking. Primarily though, getting services up and running would be great for me who develops services. Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

2 1

Re: [ros-diffs] [gvg] 17985: Return atom length when requested. Fixes bug 793.
by Hartmut Birr 23 Sep '05

23 Sep '05

gvg(a)svn.reactos.com wrote: >Return atom length when requested. Fixes bug 793. > >Modified: trunk/reactos/lib/rtl/atom.c >Modified: trunk/reactos/subsys/win32k/ntuser/class.c > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/lib/rtl/atom.c* > >--- trunk/reactos/lib/rtl/atom.c 2005-09-22 20:17:55 UTC (rev 17984) >+++ trunk/reactos/lib/rtl/atom.c 2005-09-22 20:24:50 UTC (rev 17985) >@@ -610,6 +610,10 @@ > > *NameLength = Length; > } > } > > >+ else if (NameLength != NULL) >+ { >+ *NameLength = (Entry->NameLength + 1) * sizeof(WCHAR); >+ } > > > > return Status; > } >@@ -651,6 +655,10 @@ > > > *NameLength = Length; > } > } > > >+ else if (NameLength != NULL) >+ { >+ *NameLength = (Entry->NameLength + 1) * sizeof(WCHAR); >+ } > > > } > else > { > > > ------------------------------------------------------------------------ Entry is uninitialized at this two points. - Hartmut

2 3

Moving onto 0.3 with networking
by Murphy, Ged (Bolton) 23 Sep '05

23 Sep '05

As one of our main features for 0.3, we can't progress out of the 0.2.* releases until it is either complete, or the goalposts are moved. With nobody working on networking at the moment, 0.2.8 seems likely and I'm starting to wonder how far into the 0.2.* releases we are going to go. Also, at what stage will the network model be enough to satisfy a 0.3 release? Does this just mean stable, basic TCP/IP with basic ws2_32 support? How many drivers need to be supported? What about service providers for ws2_32.dll (Mswsock.dll is stubbed apart from TransmitFile, and Wshtcpip.dll is non existent) What about NDIS? Change in circumstances has just released most of my evenings now, however although I'm starting to work on networking apps, and hopefully soon User Mode code, my coding skills and windows knowledge are not yet up to a level where I can tackle the more in-depth stuff, especially kernel mode (eek) Does any one plan to, or is anyone going to volunteer to take up networking? I would be more than happy to throw all my spare time into helping them in any way possible. If we glean some information from this email, I can start to document it in the wiki (we don't have much networking documentation in there at the moment) Regards, Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

3 2

Re: [ros-dev] Starcraft Setup BSODs due to KMODE_EXCEPTION_NOT_HANDLED
by eek2121＠comcast.net 23 Sep '05

23 Sep '05

Try using a crack and seeing if it works then. I know there was work done on DirectDraw, so you might have some luck. > Glad I could help you, and help get my favorite game working on ReactOS. > > BTW, the colors on the liltle setup title program (or whatever you call > it) where weird. Just skin deep, and starcraft finished installation as > usual. However, it fails the CD test as it usually does. > > Ge van Geldorp wrote: > > >>From: Reuben Perelman > >> > >> > >> > >>>Ge van Geldorp wrote: > >>>Does the patch below fix this? > >>> > >>> > >> > >>Yes it does. > >> > >> > > > >Ok, thanks for testing. The patch is an ugly hack and I don't want to commit > >it. But at least I know what's going on now and can think about a better > >patch. > > > >Ge van Geldorp. > > > >_______________________________________________ > >Ros-dev mailing list > >Ros-dev(a)reactos.com > >http://reactos.com:8080/mailman/listinfo/ros-dev > > > > > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev

7 12

Linux Distribution installed...
by Rick Langschultz 22 Sep '05

22 Sep '05

Which linux distro is reactos.com based on? And what are the major software packages installed? Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

4 4

Re: [ros-dev] Starcraft Setup BSODs due to KMODE_EXCEPTION_NOT_HANDLED
by eek2121＠comcast.net 21 Sep '05

21 Sep '05

As a temporary solution a DirectDraw->GDI renderer could be written. Just an idea, anyways, i hope to commit a DirectDraw test app later today, and once i get my build environment set back up i will work on DirectDraw. > DirectDraw will not work yetr in ros. we are missing to much of it. if we > want directdraw working. we need implement alot more stuff in win32k, gdi32 > and ddraw.dll > > Status : noting works yet. to create a surface. > some work en reusare have been made. When I can contiune or some else on > directx devlioing I do not know when it will happen again. > > > ----- Original Message ----- > From: <eek2121(a)comcast.net> > To: "ReactOS Development List" <ros-dev(a)reactos.com> > Sent: den 21 September 2005 16:37 > Subject: Re: [ros-dev] Starcraft Setup BSODs due to > KMODE_EXCEPTION_NOT_HANDLED > > > > Try using a crack and seeing if it works then. I know there was work done > on DirectDraw, so you might have some luck. > > > > > > > Glad I could help you, and help get my favorite game working on ReactOS. > > > > > > BTW, the colors on the liltle setup title program (or whatever you call > > > it) where weird. Just skin deep, and starcraft finished installation as > > > usual. However, it fails the CD test as it usually does. > > > > > > Ge van Geldorp wrote: > > > > > > >>From: Reuben Perelman > > > >> > > > >> > > > >> > > > >>>Ge van Geldorp wrote: > > > >>>Does the patch below fix this? > > > >>> > > > >>> > > > >> > > > >>Yes it does. > > > >> > > > >> > > > > > > > >Ok, thanks for testing. The patch is an ugly hack and I don't want to > commit > > > >it. But at least I know what's going on now and can think about a > better > > > >patch. > > > > > > > >Ge van Geldorp. > > > > > > > >_______________________________________________ > > > >Ros-dev mailing list > > > >Ros-dev(a)reactos.com > > > >http://reactos.com:8080/mailman/listinfo/ros-dev > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Ros-dev mailing list > > > Ros-dev(a)reactos.com > > > http://reactos.com:8080/mailman/listinfo/ros-dev > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.com > > http://reactos.com:8080/mailman/listinfo/ros-dev > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Anti-Virus. > > Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date: 2005-09-20 > > > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev

2 1

Re: [ros-dev] Starcraft Setup BSODs due to KMODE_EXCEPTION_NOT_HANDLED
by michael＠fritscher.net 21 Sep '05

21 Sep '05

There is already a test app in rosapps\demos\ddraw\ > As a temporary solution a DirectDraw->GDI renderer could be written. > > Just an idea, anyways, i hope to commit a DirectDraw test app later today, > and once i get my build environment set back up i will work on DirectDraw. > > >> DirectDraw will not work yetr in ros. we are missing to much of it. if >> we >> want directdraw working. we need implement alot more stuff in win32k, >> gdi32 >> and ddraw.dll >> >> Status : noting works yet. to create a surface. >> some work en reusare have been made. When I can contiune or some else on >> directx devlioing I do not know when it will happen again. >> >> >> ----- Original Message ----- >> From: <eek2121(a)comcast.net> >> To: "ReactOS Development List" <ros-dev(a)reactos.com> >> Sent: den 21 September 2005 16:37 >> Subject: Re: [ros-dev] Starcraft Setup BSODs due to >> KMODE_EXCEPTION_NOT_HANDLED >> >> >> > Try using a crack and seeing if it works then. I know there was work >> done >> on DirectDraw, so you might have some luck. >> > >> > >> > > Glad I could help you, and help get my favorite game working on >> ReactOS. >> > > >> > > BTW, the colors on the liltle setup title program (or whatever you >> call >> > > it) where weird. Just skin deep, and starcraft finished installation >> as >> > > usual. However, it fails the CD test as it usually does. >> > > >> > > Ge van Geldorp wrote: >> > > >> > > >>From: Reuben Perelman >> > > >> >> > > >> >> > > >> >> > > >>>Ge van Geldorp wrote: >> > > >>>Does the patch below fix this? >> > > >>> >> > > >>> >> > > >> >> > > >>Yes it does. >> > > >> >> > > >> >> > > > >> > > >Ok, thanks for testing. The patch is an ugly hack and I don't want >> to >> commit >> > > >it. But at least I know what's going on now and can think about a >> better >> > > >patch. >> > > > >> > > >Ge van Geldorp. >> > > > >> > > >_______________________________________________ >> > > >Ros-dev mailing list >> > > >Ros-dev(a)reactos.com >> > > >http://reactos.com:8080/mailman/listinfo/ros-dev >> > > > >> > > > >> > > > >> > > >> > > _______________________________________________ >> > > Ros-dev mailing list >> > > Ros-dev(a)reactos.com >> > > http://reactos.com:8080/mailman/listinfo/ros-dev >> > _______________________________________________ >> > Ros-dev mailing list >> > Ros-dev(a)reactos.com >> > http://reactos.com:8080/mailman/listinfo/ros-dev >> > >> > >> > -- >> > No virus found in this incoming message. >> > Checked by AVG Anti-Virus. >> > Version: 7.0.344 / Virus Database: 267.11.3/107 - Release Date: >> 2005-09-20 >> > >> > >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.com >> http://reactos.com:8080/mailman/listinfo/ros-dev > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.com > http://reactos.com:8080/mailman/listinfo/ros-dev >

1 0

Re: [ros-svn] [hbirr] 17912: The share disposition isn't necessary for FILE_READ_ATTRIBUTES.
by Thomas Weidenmueller 21 Sep '05

21 Sep '05

hbirr(a)svn.reactos.com wrote: > The share disposition isn't necessary for FILE_READ_ATTRIBUTES. Actually this prevents opening the file during the operation. A better candidate for GetFileAttributesEx is NtQueryFullAttributesFile which accepts a OBJECT_ATTRIBUTES structure instead of a handle, so there's no need to even open the file at all. Best Regards, Thomas

2 1

Lost my password...
by eek2121＠comcast.net 21 Sep '05

21 Sep '05

Who do i contact to retrieve/reset my SVN password?

2 1

chill out
by Luke Kenneth Casson Leighton 21 Sep '05

21 Sep '05

if someone knows where richard lives could they please blow lots of ganga into the aircon ducts of his house, please. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

5 4

Starcraft Setup BSODs due to KMODE_EXCEPTION_NOT_HANDLED
by Reuben Perelman 21 Sep '05

21 Sep '05

Launching setup.exe on the starcraft CD immediatly causes a BSOD. Part of what it says on the BSOD is says: "The Problem Seems to be caused by the following file: win32k.sys KMODE_EXCEPTION_NOT_HANDLED" Attached is a screenshot of the BSOD. I would have put this on bugzilla if bugzilla hadn't given me the error: " The 'bug number' // is invalid. If you are trying to use QuickSearch, you need to enable JavaScript in your browser. To help us fix this limitation, add your comments to bug 70907 <http://bugzilla.mozilla.org/show_bug.cgi?id=70907>."

3 7

OT: HTA Embedding
by Rick Langschultz 21 Sep '05

21 Sep '05

Hello, I know this is a bit off topic but I was wondering if anyone knew how to embed an HTA inside a c++ application. I know that the Add / Remove Programs control panel applet uses HTAs to display registry settings. I want to do sort of the same thing with my app. Rick Langschultz rlangschultz(a)cox.net (Home) rlangschultz(a)ellemaespa.com (Work) rlangschultz(a)email.uophx.edu (School)

2 1

Re: [ros-svn] [royce] 17958: always strip '^' (unless it was preceded by an '^' itself), not just if it precedes the redirection symbols - fixes some of my test cases in seta_test.cmd
by Royce Mitchell III 21 Sep '05

21 Sep '05

royce(a)svn.reactos.com wrote: >always strip '^' (unless it was preceded by an '^' itself), not just if it precedes the redirection symbols - fixes some of my test cases in seta_test.cmd > > >Updated files: >trunk/reactos/subsys/system/cmd/set.c > > "set /a" and "if [not] ==" now work perfectly as far as I'm aware. seta_test.cmd runs successfully in our cmd.exe now.

1 0

Re: [ros-dev] compiling botched version of dcethreads exception using pthread-win32 - WORKS!
by Luke Kenneth Casson Leighton 20 Sep '05

20 Sep '05

dear hackbunny, regarding your request for information about the number of occurrences of the "FINALLY" macro, here they are. not as many. don't know why you're interested, love to know - some other time. find . -name "*.[ch]" | xargs grep FINALLY | wc 19 71 938 -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 1

Fresh current D/L from SVN fails to build
by Robert Dickenson 20 Sep '05

20 Sep '05

After updating my binutils to the current candidate release at mingw.org and continuing my build it fails with the following: S:\REACTOS\trunk\reactos>make [RBUILD] makefile.auto Reading build files...done Detecting compiler...detected (gcc) Detecting binutils...detected (ld) Detecting netwide assembler...detected (nasm) Detecting compiler -pipe support...detected Detecting compiler pre-compiled header support...not detected Processing modules...done Creating directories...done Unpacking WINE resources...done Generating test support code...done Generating proxy makefiles...done Checking automatic dependencies...done [DLLTOOL] obj-i386\lib\kernel32\libkernel32.a [MKDIR] obj-i386\tools\winebuild <snip> [CC] apps\utils\net\whois\whois.c [WRC] obj-i386\apps\utils\net\whois\whois.coff [LD] output-i386\apps\utils\net\whois\whois.exe [RSYM] output-i386\apps\utils\net\whois\whois.exe [DLLTOOL] obj-i386\lib\version\libversion.a [DLLTOOL] obj-i386\lib\gdi32\libgdi32.a [DLLTOOL] obj-i386\lib\ntdll\libntdll.a [CC] apps\utils\rosperf\rosperf.c [CC] apps\utils\rosperf\lines.c [CC] apps\utils\rosperf\fill.c [CC] apps\utils\rosperf\text.c [CC] apps\utils\rosperf\testlist.c [WRC] obj-i386\apps\utils\rosperf\rosperf.coff [LD] output-i386\apps\utils\rosperf\rosperf.exe [RSYM] output-i386\apps\utils\rosperf\rosperf.exe [CC] apps\utils\ps\ps.c In file included from include/ndk/ntndk.h:39, from apps/utils/ps/ps.c:27: include/ndk/extypes.h:174: warning: redefinition of `LANGID' w32api/include/winnt.h:136: warning: `LANGID' previously declared here make: *** [obj-i386\apps\utils\ps\ps.o] Error 1 S:\REACTOS\trunk\reactos>toolsver NASM version 0.98 GNU ld version 2.16.91 20050827 GNU dlltool 2.16.91 20050827 GNU windres 2.16.91 20050827 Copyright 2005 Free Software Foundation, Inc. Reading specs from C:/MinGW/bin/../lib/gcc-lib/mingw32/3.3.1/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host= mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable -languages=c,c++,f77,objc,ada,java --disable-win32-registry --disable-shared --e nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-ja va-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization Thread model: win32 gcc version 3.3.1 (mingw special 20030804-1) GNU nm 2.16.91 20050827 GNU Make 3.80 Cleaning looks a little suspect as well: S:\REACTOS\trunk\reactos>make clean make: [cabman_clean] Error 1 (ignored) [MKDIR] obj-i386\tools\cdmake [CC] tools\cdmake\cdmake.c [CC] tools\cdmake\llmosrt.c [MKDIR] output-i386\tools\cdmake [LD] output-i386\tools\cdmake\cdmake.exe [MKDIR] obj-i386\tools\mkhive [CC] tools\mkhive\binhive.c [CC] tools\mkhive\infcache.c [CC] tools\mkhive\mkhive.c [CC] tools\mkhive\reginf.c [CC] tools\mkhive\registry.c [MKDIR] output-i386\tools\mkhive [LD] output-i386\tools\mkhive\mkhive.exe [MKDIR] obj-i386\tools\rbuild\tests make: [widl_clean] Error 1 (ignored) S:\REACTOS\trunk\reactos>

1 0

moving discussion of freedce/win32 to freedce-devel
by Luke Kenneth Casson Leighton 20 Sep '05

20 Sep '05

dear reactos developers, after receiving some much appreciated advice i have made a decision: i will not be posting to the ros-dev lists (unless invited to do so). if you wish to discuss the porting of freedce to win32, or to find out about its progress, the freedce-devel mailing list is where i believe that to be most appropriate. l. p.s. banning people on freedce-devel is not even considered let alone discussed. that's mainly because not much is discussed there at all in fact, it's a pretty low-traffic list :) -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

2 1

Re: [ros-dev] found it! the "dce porting" header file
by Luke Kenneth Casson Leighton 20 Sep '05

20 Sep '05

dear hackbunny, regarding your comments about screaming in pain and having teeth pulled because of pthreads-win32, i am so so sorry: i cannot help you there. i don't have the time nor the expertise. i posted (some time afterwards) a message indicating just how many occurrences of DCE exception macros there are - it's literally hundreds. at least pthreads-win32 "gets something going". i believe strongly in "GetItWorking(tm)" and "RewriteLaterAfterProvingItWorks(tm)". i _don't_ believe in throwing everything away just because one way to get things up and running quickly happens not to be the nicest solution. it's a matter of priorities. plus, like i said in my previous reply, DCE exceptions deal with networking and memory errors in a runtime environment where application designers _know_ that there's going to be order-of-milliseconds delays. the usual speed-critical criteria which make people run away screaming about exceptions simply do not apply. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Re: [ros-dev] found it! the "dce porting" header file
by Luke Kenneth Casson Leighton 20 Sep '05

20 Sep '05

dear hyperion, sorry for not getting back to this one earlier. regarding hacking up a replacement for the DCE compatible threads library: GREAT. i have made a start by removing the POSIX Draft 4 threading requirements, which has been on the cards for like ... ermmm... five years. see http://sf.net/projects/freedce, cvs requirements, see dcethreads-win32 give me a while to commit what i've done so far. there's actually very little code left, because of pthreads-win32. the only stuff left in dcethreads-win32 is actually the DCE exception handling stuff. which i understand is right in your area of expertise :) btw: one important point. it is NOT, i repeat NOT important that "speed be of the essence". the usual argument "exceptions are expensive and therefore evil" simply doesn't apply. exceptions in DCE are used to catch memory and _networking_ errors. _networking_ errors. order of milliseconds and greater. DCE/RPC applications (the Windows NT 4.0 Domains and Administrative suite are good - and relevant - examples) are _designed_ with networking errors and networking delays taken into consideration and into account. the only instance where someone didn't bother to take networking into account is the idiots who ported win16 (yes, win16, remember we're talking Windows NT 3.1 here - where do you think win32 came from? not from the idiots in the win95 team :) printing API to spoolss (taking the "blobs" as [in,out] parameters - imagine what _that_ does when you have the double-function-call thing, the first one to ask how big a "blob" to allocate). but i digress... -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Re: [ros-dev] found it! the "dce porting" header file
by Luke Kenneth Casson Leighton 20 Sep '05

20 Sep '05

[dear ros-dev developers, i'm "on-list" but have "receive postings disabled" because i have far too much on my plate to deal with right now. i'm sorry i haven't got back to people] saveliy, hi, you asked if freedce is useable: the answer is yes [with conditions]. freedce is the _reference_ implementation from http://opengroup.org/dce. and it is autoconf'd. therefore, asking "is it fully featured" the answer is it _is_ the features :) :) now. microsoft "embraced and extended" DCE/RPC actually the 1.1 reference implementation because it's OSF 1.1 Free Software BSD-Compatible license... what am i doing, what am i doing, see this: http://en.wikipedia.org/wiki/MSRPC :) i've added certain "missing" features to freedce and it's now on-wire compatible and IDL-compatible with MSRPC. what it _doesn't_ yet do is output MSRPC-binary-compatible stuff which people are referring to on wine lists as "type libraries". hope this helps. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

1 0

Re: [ros-svn] [gdalsnes] 17923: -added better LIST_FOR_EACH macros (ripped from wine) and fix their usage
by Steven Edwards 19 Sep '05

19 Sep '05

Hi, --- gdalsnes(a)svn.reactos.com wrote: > -added better LIST_FOR_EACH macros (ripped from wine) and fix their usage > -make hotkeys session global (they dont belong in winsta) > Updated files: > trunk/reactos/include/reactos/helper.h These are in include/wine/list.h right? Are you duplicating the macros or are you using them from there? Sorry I don't have time to review the diff. Thanks Steven __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev