Ros-dev

ros-dev@reactos.org

5789 discussions

by Rick Langschultz

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)

19 years, 7 months

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

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.

19 years, 7 months

Re: [ros-dev] compiling botched version of dcethreads exception using pthread-win32 - WORKS!

by Luke Kenneth Casson Leighton

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> --

19 years, 7 months

Fresh current D/L from SVN fails to build

by Robert Dickenson

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>

19 years, 7 months

moving discussion of freedce/win32 to freedce-devel

by Luke Kenneth Casson Leighton

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> --

19 years, 7 months

Re: [ros-dev] found it! the "dce porting" header file

by Luke Kenneth Casson Leighton

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> --

19 years, 7 months

Re: [ros-dev] found it! the "dce porting" header file

by Luke Kenneth Casson Leighton

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> --

19 years, 7 months

Re: [ros-dev] found it! the "dce porting" header file

by Luke Kenneth Casson Leighton

[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> --

19 years, 7 months

Re: [ros-svn] [gdalsnes] 17923: -added better LIST_FOR_EACH macros (ripped from wine) and fix their usage

by Steven Edwards

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

19 years, 7 months

scared! freedce-win32 in a cvs repository near you

by Luke Kenneth Casson Leighton

right. 48 hours later, i've got a first version of freedce-win32 to try out, which i'm actually a bit frightened of running. just in case it works :) thank goodness for pthreads-win32, otherwise i'd be up small creek. major things todo: in ipnaf.c (actually ipnaf_linux.c or even better ipnaf_win32.c) it's necessary to write an IP-interface-enumeration function. this function presumably will call GetIpAddrTable and go over all the addresses including netmasks and broadcast addresses returning information that the rpc runtime can then "listen" on - one by one. no, freedce doesn't go listening on 0.0.0.0 it binds to all "towers" whatever they're called. because i've commented this code out (stubbed) i am not expecting freedce-win32 to work straight off. once this is working, putting it in place of rpcrt4 should be relatively straightforward (and mostly very very mind numbingly boring) - a matter of "back-converting" and following the lead of dceport.h - microsoft's "wrapper" header file that allows application developers to port DCE/RPC applications to MSRPC. i say "lead" because it's woefully inadequate, representing about 10% of the functions and structs that actually need "converting", because dceport.h contains the "publicly accessible" functions. once _that's_ done, then there will be two remaining tasks: 1) check that pthreads-win32 works under wine (!) and if so, job done, otherwise it's _yet_ another emulation layer to write, but at least the source code of pthreads-win32 represents a damn good starting point 2) mash freedce's typelib output to be compatible with MSRPC binaries. this latter is no small task (but at least it could be considered). the data structures have been _totally_ mashed, by microsoft. gotta run. later. l. -- -- <a href="http://lkcl.net">http://lkcl.net</a> --

19 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev