- Ros-dev - ReactOS.org

by Murphy, Ged (Bolton)

Are you not able to use a VM? It' makes life much easier, and IMO, it's essential for development work. ROS does have one or two problems with real hardware at the moment, and it's hard to pinpoint without a debugger. If you can get a photo of the BSOD, it would help. -----Original Message----- From: Peter Quiring [mailto:pquiring@gmail.com] Sent: 26 April 2006 17:23 To: ros-dev(a)reactos.org Subject: [ros-dev] need help debugging Hi all, I'm new to ROS but I've had a few patches accepted to Wine. I'm having difficulty with the website and I can't seem to login (even after enabling multisession) so I can't use bugzilla or the forums. So anyways, I've got ROS to compile (RosBE is great!)/build/install on two systems but I'm getting the following problems on one system (Dell Inspiron 5150 Laptop): During install it shows a 17592185991168 MB unused space partition after my 60 GB FAT32 partition. But install still works okay. During 1st boot I get a bsod, I don't have a COM port (USB only) so I tried to use the SCREEN output option but it's too fast to read. I've try to use the FILE option but only 600+ bytes are written to the debug.log file. I know the cache_manager isn't being flushed because everytime it crashes the contents of the folders in "Documents & settings" folder are corrupt (ie: "All Users.Reactos", etc.) So my question is : How can I disable the cache_manager? Or can I place sync() commands somewhere in the source for testing. (is there such a function available?). The bsod seems to be related to gdi issues during creating the primary surface. Somewhere the DeviceObject for the screen is NULL and is not caught till it causes a GPE much later. I'll give a little info that I've written down. /ntoskrnl/io/irp.c:570 - GPE /ntoskrnl/io/irp.c:911 /subsystems/win32/win32k/objects/dc.c:693 /subsystems/win32/win32k/ntuser/winsta.c:348 /subsystems/win32/win32k/ntuser/guicheck.c:57 /subsystems/win32/win32k/objects/dc.c:853 /subsystems/win32/win32k/ntuser/windc.c:121 /subsystems/win32/win32k/ntuser/windc.c:441 /subsystems/win32/win32k/ntuser/windc.c:529 /subsystems/win32/win32k/ntuser/windc.c:101 /ntoskrnl/ke/traps.c:306 /dll/win32/user32/windows/dialog.c:696 Hope this helps. I was using the lastest SVN at the time (21738 I think). Thanks. Peter Quiring _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/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

19 years, 4 months

1
0
0 0

RE: [ros-dev] RE: ncpa

by Murphy, Ged (Bolton)

Ge van Geldorp wrote: > > > From: Murphy, Ged (Bolton) > > > > I was thinking along the lines of stopping the DHCP service > > and calling AddIPAddress, which should be the same as > > inserting the address manually in the registry. I haven't > > looked into this though, so might not work. > > I kind of like the Windows design: the DHCP client service is actually > implemented in dhcpcsvc.dll (you can see the "ServiceMain" > export). This > allows concentration of all usermode IP address/registry > stuff in one DLL. > AddIPAddress would then call into dhcpcsvc. Do you know how much work would be involved in moving our DHCP client into dhcpcsvc and implementing everything around this? If it's quite a lot of work it might be worth me trying out what I mentioned, just has a hack until we have time to do things the Windows way. If your ReactOS work is going to concentrate solely on the kernel now, we might be waiting a long time to get this implemented as nobody seems to want to pick ncpa up. It's become the ReactOS forbidden fruit ;) Any method would be good at this stage to get ncpa working, as it's our only missing feature for the 0.3 release. 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

19 years, 4 months

2
1
0 0

RE: [ros-dev] RE: ncpa

by Murphy, Ged (Bolton)

Ge van Geldorp wrote: > > > From: Murphy, Ged (Bolton) > > > > Is there a particular reason you were doing this via the DHCP > > client and not just using functions provided by iphlpapi? > > I couldn't find iphlpapi functions to do this. But even if > they're there, > iphlpapi will need to inform the DHCP client about the change > to static IP > address (basically telling the DHCP client to shut up and go > to sleep). I was thinking along the lines of stopping the DHCP service and calling AddIPAddress, which should be the same as inserting the address manually in the registry. I haven't looked into this though, so might not work. (stopping the service would need a temporary hack, as it's not been converted to an NT service yet, plus we don't have StartService to restart it) 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

19 years, 4 months

2
1
0 0

Non-fatal filesystem corruption?

by WaxDragon

After I had linux complain at me during a file copy onto a ReactOS partition, I checked it with dosfsck, and found all some issues. Since then I have been checking the partition I use for vmware after installs. dosfsck has been finding errors every time. I ran a quick regression test and it seems the was introduced between 0.2.8 and 0.2.9. It seems that most of these errors are non fatal, as myself and others have not noticed this causing any problems. Still, it bothers me, since it could be causing a problem somewhere. GreyGhost claimed Windows was not finding any issues with his ros partition, can anyone confirm? I'm using flat disk images under vmware and qemu, and I'm seeing this issue under both. I'm using both IDE and SCSI drives under vmware, and see the issues with both types. Anyone who is more famliar with filesystems care to comment? dosfsck of a 0.2.9(and HEAD) install: root@phoenix:/home/ford/public/virtuals/vmware/ReactOS# dosfsck -v /dev/loop0 dosfsck 2.10 (22 Sep 2003) dosfsck 2.10, 22 Sep 2003, FAT32, LFN Checking we can access the last sector of the filesystem Boot sector contents: System ID "MSWIN4.1" Media byte 0xf8 (hard disk) 512 bytes per logical sector 8192 bytes per cluster 1 reserved sector First FAT starts at byte 512 (sector 1) 2 FATs, 16 bit entries 102400 bytes per FAT (= 200 sectors) Root directory starts at byte 205312 (sector 401) 512 root directory entries Data area starts at byte 221696 (sector 433) 51125 data clusters (418816000 bytes) 63 sectors/track, 16 heads 63 hidden sectors 818433 sectors total /ReactOS/SYSTEM32/CONFIG/SYSTEM File size is 61440 bytes, cluster chain length is > 65536 bytes. Truncating file to 61440 bytes. /ReactOS/SYSTEM32/CONFIG/SOFTWARE File size is 122880 bytes, cluster chain length is > 122880 bytes. Truncating file to 122880 bytes. Checking for unused clusters. Leaving file system unchanged. /dev/loop0: 361 files, 6907/51125 clusters dosfsck of a 0.2.8 install: root@phoenix:/home/ford/public/virtuals/vmware/ReactOS# dosfsck -v /dev/loop0 dosfsck 2.10 (22 Sep 2003) dosfsck 2.10, 22 Sep 2003, FAT32, LFN Checking we can access the last sector of the filesystem Boot sector contents: System ID "MSWIN4.1" Media byte 0xf8 (hard disk) 512 bytes per logical sector 8192 bytes per cluster 1 reserved sector First FAT starts at byte 512 (sector 1) 2 FATs, 16 bit entries 102400 bytes per FAT (= 200 sectors) Root directory starts at byte 205312 (sector 401) 512 root directory entries Data area starts at byte 221696 (sector 433) 51125 data clusters (418816000 bytes) 63 sectors/track, 16 heads 63 hidden sectors 818433 sectors total Checking for unused clusters. /dev/loop0: 324 files, 5501/51125 clusters Here is a dosfsck of the scsi build disk I use under vmware, after a partial build: root@phoenix:/home/ford/public/virtuals/vmware/ReactOS# losetup -o 32256 /dev/loop0 build-scsi-flat.vmdk root@phoenix:/home/ford/public/virtuals/vmware/ReactOS# dosfsck -v /dev/loop0 dosfsck 2.10 (22 Sep 2003) dosfsck 2.10, 22 Sep 2003, FAT32, LFN Checking we can access the last sector of the filesystem Boot sector contents: System ID "MSWIN4.1" Media byte 0xf8 (hard disk) 512 bytes per logical sector 4096 bytes per cluster 32 reserved sectors First FAT starts at byte 16384 (sector 32) 2 FATs, 32 bit entries 4185088 bytes per FAT (= 8174 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 8386560 (sector 16380) 1046185 data clusters (4285173760 bytes) 63 sectors/track, 255 heads 63 hidden sectors 8385867 sectors total /REACTOS/makefile.auto File size is 2274845 bytes, cluster chain length is > 2277376 bytes. Truncating file to 2274845 bytes. /REACTOS/MEDIA/FONTS/COUR.TTF File size is 144456 bytes, cluster chain length is > 147456 bytes. Truncating file to 144456 bytes. /REACTOS/MEDIA/FONTS/.svn/text-base/cour.ttf.svn-base File size is 144456 bytes, cluster chain length is > 147456 bytes. Truncating file to 144456 bytes. /REACTOS/MEDIA/NLS/C_949.NLS File size is 196642 bytes, cluster chain length is > 200704 bytes. Truncating file to 196642 bytes. /REACTOS/MEDIA/NLS/C_932.NLS File size is 162850 bytes, cluster chain length is > 163840 bytes. Truncating file to 162850 bytes. /REACTOS/MEDIA/NLS/C_950.NLS File size is 196642 bytes, cluster chain length is > 200704 bytes. Truncating file to 196642 bytes. /REACTOS/MEDIA/NLS/C_936.NLS File size is 196642 bytes, cluster chain length is > 200704 bytes. Truncating file to 196642 bytes. /REACTOS/MEDIA/NLS/.svn/text-base/c_949.nls.svn-base File size is 196642 bytes, cluster chain length is > 200704 bytes. Truncating file to 196642 bytes. /REACTOS/MEDIA/NLS/.svn/text-base/c_932.nls.svn-base File size is 162850 bytes, cluster chain length is > 163840 bytes. Truncating file to 162850 bytes. /REACTOS/MEDIA/NLS/.svn/text-base/c_950.nls.svn-base File size is 196642 bytes, cluster chain length is > 200704 bytes. Truncating file to 196642 bytes. /REACTOS/MEDIA/NLS/.svn/text-base/c_936.nls.svn-base File size is 196642 bytes, cluster chain length is > 200704 bytes. Truncating file to 196642 bytes. /REACTOS/MEDIA/DRIVERS/ETC/SERVICES File size is 398472 bytes, cluster chain length is > 401408 bytes. Truncating file to 398472 bytes. /REACTOS/MEDIA/DRIVERS/ETC/.svn/text-base/services.svn-base File size is 390238 bytes, cluster chain length is > 393216 bytes. Truncating file to 390238 bytes. /REACTOS/subsystems/WIN32/WIN32K/INCLUDE/NAPI.H File size is 34990 bytes, cluster chain length is > 36864 bytes. Truncating file to 34990 bytes. /REACTOS/subsystems/WIN32/WIN32K/DIB/DIB8GEN.C File size is 678744 bytes, cluster chain length is > 679936 bytes. Truncating file to 678744 bytes. /REACTOS/subsystems/WIN32/WIN32K/DIB/DIB16GEN.C File size is 527182 bytes, cluster chain length is > 528384 bytes. Truncating file to 527182 bytes. /REACTOS/subsystems/WIN32/WIN32K/DIB/DIB32GEN.C File size is 254584 bytes, cluster chain length is > 258048 bytes. Truncating file to 254584 bytes. /REACTOS/INCLUDE/DDRAW.H File size is 155097 bytes, cluster chain length is > 155648 bytes. Truncating file to 155097 bytes. /REACTOS/INCLUDE/STRMIF.H File size is 271851 bytes, cluster chain length is > 274432 bytes. Truncating file to 271851 bytes. /REACTOS/INCLUDE/WINUSER.H File size is 137624 bytes, cluster chain length is > 139264 bytes. Truncating file to 137624 bytes. /REACTOS/INCLUDE/.svn Has a large number of bad entries. (37/61) Drop directory ? (y/n) some more /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/ormation.s f Start cluster beyond limit (1952542496 > 1046186). Truncating file. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/ormation.s f File size is 1634887024 bytes, cluster chain length is 0 bytes. Truncating file to 0 bytes. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/FSCK0004.REN Start cluster beyond limit (1882144357 > 1046186). Truncating file. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/FSCK0004.REN File size is 1751347823 bytes, cluster chain length is 0 bytes. Truncating file to 0 bytes. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/FSCK0005.REN Start cluster beyond limit (1953394021 > 1046186). Truncating file. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/FSCK0005.REN File size is 544830063 bytes, cluster chain length is 0 bytes. Truncating file to 0 bytes. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/--noout.tes Directory has non-zero size. Fixing it. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/--noout.tes Start cluster beyond limit (1852991008 > 1046186). Truncating file. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/d to loa.d e Directory has non-zero size. Fixing it. /REACTOS/LIB/3RDPARTY/LIBXML2/.svn/PROPS/d to loa.d e Start cluster beyond limit (1953395746 > 1046186). Truncating file. /REACTOS/LIB/3RDPARTY/LIBXML2/WIN32/WINCE/LIBXML2.VCP File size is 150203 bytes, cluster chain length is > 151552 bytes. Truncating file to 150203 bytes. /REACTOS/LIB/3RDPARTY/LIBXML2/WIN32/WINCE/.svn/text-base/libxml2.vcp.svn-base File size is 144930 bytes, cluster chain length is > 147456 bytes. Truncating file to 144930 bytes. /REACTOS/NTOSKRNL/BUGCODES.RC File size is 12664 bytes, cluster chain length is > 16384 bytes. Truncating file to 12664 bytes. /REACTOS/NTOSKRNL/INCLUDE/INTERNAL/NAPI.H File size is 13786 bytes, cluster chain length is > 16384 bytes. Truncating file to 13786 bytes. /REACTOS/NTOSKRNL/MM/SECTION.C File size is 145682 bytes, cluster chain length is > 147456 bytes. Truncating file to 145682 bytes. /REACTOS/NTOSKRNL/MM/.svn/text-base/section.c.svn-base File size is 140762 bytes, cluster chain length is > 143360 bytes. Truncating file to 140762 bytes. /REACTOS/NTOSKRNL/EX/ZW.S File size is 42498 bytes, cluster chain length is > 45056 bytes. Truncating file to 42498 bytes. /REACTOS/DLL/DIRECTX/DPLAYX/DPLAY.C File size is 175774 bytes, cluster chain length is > 176128 bytes. Truncating file to 175774 bytes. /REACTOS/DLL/DIRECTX/DPLAYX/.svn/text-base/dplay.c.svn-base File size is 170323 bytes, cluster chain length is > 172032 bytes. Truncating file to 170323 bytes. WD -- ReactOS is a hub, follow the spokes and you'll immediately find absolutely everything you need to know about Windows. ReactOS is not just software, it's people. kjk_hyperion

19 years, 4 months

2
1
0 0

Re: [Freedce-devel] pthread_clear_exit_np()

by Luke Kenneth Casson Leighton

christoph, christoph, why are you trying to insult someone who is looking to further the long-term aims and goals of free software, by putting people in touch on perceived unrelated projects and explaining to them the relevance? you have a specific area of expertise (according to your 2005 ukuug bio) - kernel development. i would welcome an opportunity for you to explain why my life, which happens to be quite poignantly sad and unfulfilling in many ways, has any relevance to the discussion at hand - and, also, if you could possibly elaborate on why i am "beeeing an asshole" likewise has any relevance. also: i would strongly advise you to consider objectively what i am trying to do - and forget what you do not know about me [you know nothing about me]. forget that i am involved in this discussion, because it is clearly affecting your (and evidently other people's) objective judgement. freedce is an important and under-recognised project that can save literally man-decades of development time currently being wasted by key free software projects, and lack of recognition for it is also stopping several interoperability projects from even _happening_. you want to know how many incompatible free software implementations there are of MSRPC around? i count FOUR, all written in c. EACH of those projects has had at least two full-time members working on them for AT LEAST three years, and each of those projects will require those full-time members to continue working on those incompatible and fundamentally non-interoperable development environments for another three to five years, to make them useful - as development environments, rather than to "fill one project's needs". [whereas, if one of the fat cat free software "supporting" companies would actually get off their backsides and fund freedce, it would save everybody several decades worth of money] you see - until such time as those non-interoperable MSRPC projects are completed, microsoft still dominates the market. MSRPC is the key infrastructure which binds everything together in the microsoft world: it's what the European Union is trying to get out of microsoft in the anti-trust case: information on how they use MSRPC; how they do their authentication; the IDL files; specifications on the nt domain services; etc. etc. you indicated in an earlier email that (please correct me if my impressions are wrong) that freedce is archaic and therefore irrelevant. nothing could be further from the truth, and your distaste for freedce is very short-sighted. mark, from ibm: you should be advocating to ibm's free software departments to back freedce and to KEEP the employees who worked on DCE 3.0 and move them to freedce and MSRPC interoperability. get some of that multi-hundred-million-dollar free software advertising budget and put a fractional percentage of it behind freedce. you don't have to _like_ freedce. you don't have to like its history. you don't have to like that it is me that is advocating its use. but don't you _dare_ insult me and think it doesn't have any effect. so. i look forward to receiving an apology from you - not for my benefit, but because it will mean that you are willing to demonstrate to the hundreds of people to whom your message has been distributed, and to the thousands of people who will encounter it in the future, that you can be trusted to make objective and important decisions. and that you don't deliberately go out of your way to belittle and bully other people. if you are unable to apologise, then you demonstrate, to me and to others, that you do not deserve any position of responsibility. am i making myself clear? l. On Tue, Apr 25, 2006 at 07:22:16PM +0200, Christoph Hellwig wrote: > luke, please get a life and stop beeing an asshole, thanks. > -- -- lkcl.net - mad free software computer person, visionary and poet. --

19 years, 4 months

4
5
0 0

ReactOS Compatibility Database (beta status)

by Klemens Friedl

The ReactOS Compatibility Database has reached beta status. URL: http://www.reactos.org/support/ The compatibility database has been designed to store application and driver data. Simply click on one of the 5 green start buttons on the frontpage to begin to browse through the database. To submit an application/driver, click on "Submit Application" (menu bar). Please have a look at the help and faq section for more information. The goal of the whole compatibility database is to provide one single unified place where a lot of compatibility data can be found. This has several advantages: For user it is easy to find out which software does already work in ReactOS and how good it work. Everyone (with a myReactOS account) can submit applications/drivers, additional information, vendor data, compatbility test reports, screenshots and post "compatibility forum" entries. In the last few months, several people asked how they could help in the ReactOS project. Now there is a way for people who don't know programming languages, etc., they can now submit their testing results to one place, the compatibility database. Note, in the compatibility database there is a link to the bugzilla related page. >From now on it will be easier for developers to check regression data, etc. There might be some glitches and bugs, if you find some please post a bugzilla bug entry, write a forum entry or write a reply here (mailing list). If someone has suggestions and/or ideas how to improve the compatibility database please write a reply, thx. Klemens Friedl

19 years, 4 months

3
3
0 0

Re: [Freedce-devel] pthread_clear_exit_np()

by Luke Kenneth Casson Leighton

On Mon, Apr 24, 2006 at 10:42:43AM -0500, Mark Brown wrote: > BTW: IBM stopped selling DCE/DFS years ago. The end of support > for the product is this month. yeh. there are universities (e.g. the authors of eLion) now hunting around to find ways to keep their systems going. ah well.

19 years, 4 months

1
0
0 0

Re: [ros-bugs] [Bug 1431] New: Regression of setup

by James Tabor

ReactOS.Bugzilla(a)reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=1431 > > Summary: Regression of setup > Product: ReactOS > Version: unspecified > Platform: VMWare 5 > OS/Version: ReactOS > Status: NEW > Severity: normal > Priority: P3 > Component: Win32 > AssignedTo: ros-bugs(a)reactos.org > ReportedBy: email1562000(a)yahoo.com > QAContact: ros-bugs(a)reactos.org > > > filezilla FTP server setup works properly in build 21454(apr-8-2006) but in > build 21725(apr-25-2006) all the drop down lists just show a series of squares > where text should be displayed. > > Could you post pics to the bug list? Thanks, James

19 years, 4 months

1
0
0 0

Re: [Freedce-devel] pthread_clear_exit_np()

by Luke Kenneth Casson Leighton

On Fri, Apr 21, 2006 at 01:52:58PM -0700, Roland McGrath wrote: > Have you considered instead using standard features as specified in POSIX > since around 1996? dce predates the posix standards - that's why all dce projects, some of them multi-hundred-million-dollar projects by ibm, fujitsu, EDS etc - have had to use posix draft 4 threading. the opengroup developers had to make a decision: they couldn't wait around for a few years while the POSIX committee made up their minds. so all the companies who were running dce/rpc applications had to write POSIX Draft 4 threading libraries for their operating systems. ibm did it. sun microsystems did it. microsoft did it (Win32 threads) when they ported the BSD-compatible OSF/1.0 licensed DCE 1.1 reference implementation to win32, as the basis of MSRPC. > What's your plan for other POSIX systems, such as Solaris? forget solaris: sun microsystems can deal with solaris. linux is the innovation leader, now, not solaris. > If you don't want to cancel threads as cancellation is defined by POSIX, > then why use cancellation instead of another mechanism that matches your needs? [long answers first, short one at end] because, despite being an absolutely critical strategic project that could save key strategic free software projects who are _not_ using it about a man-decade of development effort _each_, there is absolutely zero recognition of this and therefore absolutely zero funding of the project. luke howard uses freedce for his XAD project, which is a (proprietary) Active Directory replacement that he released THREE YEARS ago (and the samba team _still_ haven't got an active directory server replacement yet). XAD is capable of running on IBM z390 mainframes, and luke howard has won business awards for his work. because, as it is "old" code, with a very archaic and interesting development history, it needs work to be brought up-to-date. and because it needs work, and _because_ it is so very comprehensive in what it does, people misunderstand and do not appreciate its complexity, and therefore think, "i can do better than this", and fail miserably, and so it gets ignored. the gist is this: the use of cancellation is embedded very deeply into the design of this code. and there isn't anyone with the time, money, resources or immediately-available knowledge to rip a quarter of a million lines of code apart looking for a way to shoe-horn some very complex and subtle interaction _out_ of freedce so that it fits nicely with POSIX. anyone think i should try to put the "emulation" bit back into dcethreads (to re-wrap the cancellation rules of posix draft 4 but to keep the new API) and write redhat off (just like charles advised right at the beginning of this thread), let me know. l.

19 years, 4 months

1
0
0 0

RE: [ros-bugs] [Bug 1300] More deflaut icons for different file t ypes

by Murphy, Ged (Bolton)

> http://www.reactos.org/bugzilla/show_bug.cgi?id=1300 > > > greatlord(a)reactos.com changed: > > What |Removed |Added > -------------------------------------------------------------- > -------------- > Status|REOPENED |RESOLVED > Resolution| |INVALID > > > > > ------- Additional Comments From greatlord(a)reactos.com > 2006-04-20 16:45 CET ------- > This is not a vaild bug report, each program is response for > the icon for the > file format > Sorry to reply directly to this, but I don't have web access at the moment. The above is not true. Some default file icons are controled by the operating system, like .txt, .jpg, or .bmp for example. They can be over-ridden by 3rd party apps. This is a valid bug report. 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

19 years, 4 months

1
0
0 0

Re: Race in rpc__cn_network_receiver()?

by Luke Kenneth Casson Leighton

On Thu, Apr 20, 2006 at 03:04:21PM +1000, Luke Howard wrote: luke, you are a star: thank you for helping out with this. just for people's information (in case it's not been mentioned here - i must admit i forgot to notify opendce(a)opengroup.org!) about 6-8 months ago i did a coding-spree on freedce, with a view to achieving two, maybe three, major things: 1) porting to win32 (if you use pthreads-win32) 2) using posix final draft (7?) threads not posix draft 4. 3) proving to the people on wine and reactos that they have a hell of a lot of work to do (measured in man-decades) by not using the open group's DCE/RPC reference implementation. here's the gotchas that i encountered, and had to give up: - udp worked, but tcp did not - reactos had some problems at the time with the code behind ipconfig.exe (NetTransportEnum i think it was) - pthreads-win32 was too strictly posix compliant (!) and there is a cancellation exception or something which makes it fail in the dcethreads exception library tests, where linux does not fail (!) maybe this is related to what lukeh is talking about. *shrug*. anyway, the upshot is that freedce/latest-cvs also doesn't work on TCP, and thank you so much people for helping track down why. it's only been ten years so far: hopefully some time within the next decade, freedce will be used for some real MSRPC-related free software projects. l > >In rpc__cn_network_receiver(), rpc__socket_close() is called without an > >exception handler in place. According to IEEE Std 1003.1 (2004), close() > >is a cancellation point, see: > > > >http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html > > > >Given this, a receiver thread could receive a cancel whilst closing the > >socket, which will cause to entire program to abort. (We have seen this > >occur when the RPC server is under load.) > > > >A suggested fix is to move the call to rpc__socket_close() inside the > >TRY/CATCH_ALL block that removes any pending cancels. > > It seems like the real fix is to disable cancellation within > rpc__socket_close(), because in other places the OSF code appears to > assume that this is not a cancellation point. > > Ditto for open(), socket(), etc (but not I/O routines that may block). > > I should note that the Linux dcethreads library does actually disable > cancellation for these calls, however in our own DCE thread library > we opted not to override any system calls to avoid changing semantics > when used by non-DCE code. > > -- Luke > > -- > -- -- lkcl.net - mad free software computer person, visionary and poet. --

19 years, 4 months

1
0
0 0

Re: [Qemu-devel] Reactos SVN + Kqemu fails

by WaxDragon

I just did some digging around, and this issue was introduced somewhere between 20902 and 20911. Alex was working on the kernel heavily at the time, and there are several intertwined commmits IIRC. I just tested 20902 with both kqemu (and -kernel-kqemu) and it installed fine, and ran as well as I remember it did. It was noticably faster. On 4/17/06, WaxDragon <waxdragon(a)gmail.com> wrote: > This bug has been around for a while. > > On 4/17/06, Víctor Córcoles López <vcorcoles25(a)hotmail.com> wrote: > > Reactos 0.3.0 SVN + kqemu fails as guest O.S. It fails in both systems, > > Linux host and Windows Host. Without kqemu the reactos 0.3.0 SVN runs with > > less bugs. > > > > In VMWARE host, this bug not apear. > > > > I Send a screenshot of failure. > > WD -- ReactOS is a hub, follow the spokes and you'll immediately find absolutely everything you need to know about Windows. ReactOS is not just software, it's people. kjk_hyperion

19 years, 5 months

2
1
0 0

Re: [ros-diffs] [greatlrd] 21611: kjk_hyperion : "Breaking auditing lock for a temporary fix: allow ExEnterCriticalRegionAndAcquireFastMutexUnsafe and ExReleaseFastMutexUnsafeAndLeaveCriticalRegion to be called from any thread; fixes UserEnterShared, UserEnterExclusive and UserLeave in win32k"

by Alex Ionescu

greatlrd(a)svn.reactos.org wrote: > Author: greatlrd > Date: Sun Apr 16 20:04:28 2006 > New Revision: 21611 > > URL: http://svn.reactos.ru/svn/reactos?rev=21611&view=rev > Log: > kjk_hyperion : "Breaking auditing lock for a temporary fix: allow ExEnterCriticalRegionAndAcquireFastMutexUnsafe and ExReleaseFastMutexUnsafeAndLeaveCriticalRegion to be called from any thread; fixes UserEnterShared, UserEnterExclusive and UserLeave in win32k" > > Modified: > trunk/reactos/ntoskrnl/ex/fmutex.c > > Modified: trunk/reactos/ntoskrnl/ex/fmutex.c > URL: http://svn.reactos.ru/svn/reactos/trunk/reactos/ntoskrnl/ex/fmutex.c?rev=21… This fix is broken. The real problem is win32k, you should fix that instead. Best regards, Alex Ionescu

19 years, 5 months

2
2
0 0

RE: [greatlrd] 21644: fix 16 to 16 soyrce dest why the hell does th 16bitmap surface calls into this

by Ge van Geldorp

> From: greatlrd(a)svn.reactos.org > > Log: > fix 16 to 16 soyrce dest why the hell does th 16bitmap surface calls > into this The "16 -> 16 copy" in the DPRINT1 is a copy/paste mistake, it should read "24 -> 24 copy". Your fix is incorrect. What needs to be done in this case is process one pixel at a time, calling XLATEOBJ_iXlate on each one. GvG

19 years, 5 months

2
1
0 0

gdb question

by Saveliy Tretiakov

Hi. I'm trying to debug ros with gdb (according to GvG's tutorial) and I have a problem. After I attach gdb, reactos boots into desktop and then freezes with endless sigservs. Mouse cursor is not moving. Any ideas? (gdb) target remote localhost:567 Remote debugging using localhost:567 0x800a8297 in ?? () (gdb) continue Continuing. *** Now ros boots into desktop. *** Program received signal SIGSEGV, Segmentation fault. 0x0040aa12 in ?? () (gdb) continue Continuing. Can't send signals to this remote system. SIGSEGV not sent. Program received signal SIGSEGV, Segmentation fault. 0x0040aa12 in ?? () (gdb) continue Continuing. Can't send signals to this remote system. SIGSEGV not sent. Program received signal SIGSEGV, Segmentation fault. 0x0040aa12 in ?? () ......

19 years, 5 months

2
1
0 0

compiler error

by Reuben Perelman

> [CC] dll/win32/wininet/cookie.c > [CC] dll/win32/wininet/dialogs.c > [CC] dll/win32/wininet/ftp.c > [CC] dll/win32/wininet/gopher.c > [CC] dll/win32/wininet/http.c > dll/win32/wininet/http.c:62:23: inet_ntop.c: No such file or directory > dll/win32/wininet/http.c: In function `HTTP_HttpOpenRequestW': > dll/win32/wininet/http.c:1154: warning: implicit declaration of > function `inet_ntop' > make: *** [obj-i386/dll/win32/wininet/http.o] Error 1 It looks like it's trying to include a file that doesn't exist. Maybe somebody forgot to run "svn add inet_ntop.c" before they committed their changes?

19 years, 5 months

3
3
0 0

FW: React OS

by Ge van Geldorp

> From: Gunnar Modin <gunnar.modin(a)telia.com> > Sent: Saturday, April 15, 2006 21:31 > To: ros-dev-owner(a)reactos.org > Subject: React OS > > I just woder if there is any way I can perticipate in the > development of the OS. > > I have an masterthesis to do on my education at the Mid > Sweden university. > The project shell due for about four mounth on full time. The > plan is to do it on half time the coming winter. > > The topics that I have studied are Distributed Systems and > Networkning. > I have jused both C++ and Java as programming laguage. I also > did an projekt in Distrubuted system regarding XML and acess. > In Networking I studied IPv6 in more detail. > > Best regards > > Gunnar Modin >

19 years, 5 months

2
1
0 0

Cache manager rewrite branch

by Maarten Bosma

Hi, I'd like to give you a little report on the status of the cache manager rewrite branch. Since Filip and Hartmut are gone no one worked on it, though the actual functionality is already completed since the first commit in February 2005 and the code just needs to debugged. So decided to give it a try and merged the changes from trunk in there. I had to recreated the branch, from the last unlocked revision because of all the directory movements and tortoise merge having problems with them. I also did some debugging work on it. I have stored my results in the bugzilla bugs 942, 1360 and 1362. These are the only bugs I know of which hinder the branch from being merged to trunk. I am going on holiday tomorrow, so it would be nice if anyone else could continue working on fixing them. You can also help testing because we should do a lot of testing before merging. Especially file IO intensive applications, like installers need testing. Also the ext2fs branch, Microsoft's ntfs.sys and Vmware tools could work. But I haven't tested any of them. I will provide a patch to trunk so you do not have to check out or switch to the branch which is quite annoying, because all the locked entries are checked out again. Hopefully the new cache manager will be in place when I am back. Best Regards Maarten Bosma

19 years, 5 months

2
4
0 0

[ros-diffs] [gedmurphy] 21550: revert comctl32 Wine sync. There are some issues with it and I don't have time to fix it at the moment.

by James Tabor

Hi! URL: http://svn.reactos.ru/svn/reactos?rev=21550&view=rev Log: revert comctl32 Wine sync. There are some issues with it and I don't have time to fix it at the moment. Tonight, I will have time to check and see what we need to make this work. Thanks, James

19 years, 5 months

3
2
0 0

Re: [ros-bugs] [Bug 1358] Metabug for w3seek's patches

by James Tabor

ReactOS.Bugzilla(a)reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=1358 > > > tomasgroth(a)yahoo.dk changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > BugsThisDependsOn|1342 | > > > > Hi! What is the status of these bugs? Have all of them been added to the tree yet? Thanks, James

19 years, 5 months

2
2
0 0

Re: [ros-bugs] [Bug 1363] NdisWriteConfiguration has a bug when writing integers.

by Jerry

I complied and tested this patch on Qemu, and it seems to work. Any comments? ReactOS.Bugzilla(a)reactos.org wrote: > http://www.reactos.org/bugzilla/show_bug.cgi?id=1363 > > > crashfourit(a)gmail.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Attachment #718 is|0 |1 > obsolete| | > > > > > ------- Additional Comments From crashfourit(a)gmail.com 2006-04-09 23:33 CET ------- > Created an attachment (id=731) > --> (http://www.reactos.org/bugzilla/attachment.cgi?id=731&action=view) > NdisWriteConfiguration write integer bug fix. (v. 2) > > >

19 years, 5 months

2
1
0 0

RE: [ros-dev] ncpa

by Murphy, Ged (Bolton)

Aleksey Bragin wrote: > 'I read this code and it looked clean to me' line means that > the commiter > read the code, and assures all or some parts of the following: > 1. The code doesn't match any reverse-engineered rules (as on > wiki page regarding Audit) > 2. The code is publically documented > 3. The code has nothing to do with reverse engineering (has either > completely different implementation from the windows one - > example freeldr > vs. ntldr/osloader, or doesn't have any counterpart in > windows at all). Then why not describe it using one of the above reasons? A note such as 'This code uses MSDN documented functions only' is clear and useful. A note saying 'I read this code and it looked clean to me' isn't and could mean anything. > > It gives a good base point for us to start our defence from. > We are not under attack. We are just doing some preventive measures. I know. I said 'if the cleanliness of the code is ever questioned again'. If that does happen, it could be in the form of an attack from an outside company. Having a better analysis as to why something was unlocked would be advantageous if this situation ever arose. > > This was all decided when we originally locked the code, > > but no one has been following it. > arty, w3seek, me have been following this rules on the > possibly dirty code, so please don't speak for everyone. I don't mean the auditing methods, I mean the lack of useful message. I'm not accusing or judging anyone, I'm just trying to get a better unlocking system in place. As the code we audit gets closer to the border line of clean and dirty, we're gonna need to ensure we don't leave messages like 'yep, looks ok to me' I hope mail this isn't coming across to anyone as argumentative. It's difficult to have a conversation over email without it sounding hostile. It isn't meant that way :) 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

19 years, 5 months

1
0
0 0

RE: [ros-dev] ncpa

by Murphy, Ged (Bolton)

If the author has been contacted, it should be noted in the commit log. That alone is enough reason to squash any doubts anyone had. The authors word is always trusted. If the author couldn't be contacted, then the code should go through the audit procedure Art put forward. Whichever part of that procedure was passed should be noted in the commit log. Even if it's just something as simple as 'this code uses is fully documented on XYZ: http://..' Doing things this way ensures we can look back at the code if the cleanliness of the reversing methods is ever questioned again. It gives a good base point for us to start our defence from. This was all decided when we originally locked the code, but no one has been following it. Thus we have terms like 'I read this code and it looked clean to me'. IMO, that isn't worth anything. I could read parts of the kernel and it appear to be clean to me. Contacting Alex or correctly auditing the code would prove otherwise. In light of this, I think some of the audit measures we went to were a bit of an over reaction. Perhaps we should have only decided to audit kernel mode code, or subsections of it. However we choose to do everything and I'm a firm believer in the phrase 'If you going to do something, do it right' Ged. -----Original Message----- From: Saveliy Tretiakov [mailto:saveliyt@mail.ru] Sent: 07 April 2006 13:52 To: ReactOS Development List Subject: Re: [ros-dev] ncpa I always contact authors when it is possible. Some authors have left project years ago and are unreachable. Murphy, Ged (Bolton) wrote: >The authors of the code should always be contacted before unlocking unless >the app it produces isn't a part of Windows. > >Not doing so undermines the audit process and commit lines like 'I looked at >this code and it appears clean' is doing just that. > >Ged. > >-----Original Message----- >From: Saveliy Tretiakov [mailto:saveliyt@mail.ru] >Sent: 07 April 2006 13:11 >To: ReactOS Development List >Subject: Re: [ros-dev] ncpa > > >Do we need to audit ncpa? > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/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 > > >_______________________________________________ >Ros-dev mailing list >Ros-dev(a)reactos.org >http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/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

19 years, 5 months

2
1
0 0

RE: [ros-dev] ncpa

by Murphy, Ged (Bolton)

The authors of the code should always be contacted before unlocking unless the app it produces isn't a part of Windows. Not doing so undermines the audit process and commit lines like 'I looked at this code and it appears clean' is doing just that. Ged. -----Original Message----- From: Saveliy Tretiakov [mailto:saveliyt@mail.ru] Sent: 07 April 2006 13:11 To: ReactOS Development List Subject: Re: [ros-dev] ncpa Do we need to audit ncpa? _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/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

19 years, 5 months

2
1
0 0

ncpa

by Murphy, Ged (Bolton)

This is all that stands in the way of getting 0.3.0 out the door. As soon as we can config the network adapters via the dialog, we can branch and start bug hunting. This would also be a good time to enlist some more testers under the Munger wing ;) I'm going to have a look at this tonight, but I've had a look before and IIRC, I had trouble hunting the bug down. It would be good if someone with a bit more experience in this area could have a look. I think Gé was working on this before Christmas, so I'm hopefully gonna catch up with him tonight via IM, as I'm not sure if he's subscribed to ros-dev anymore. We've been promising this for about 18 months now. I know a hell of a lot of work has been done in other areas (in fact, the jump from 0.3 to 0.4 should be relatively small as much of the 0.4 work is done), but we need to deliver. After all the recent goings on, getting 0.3.0 would be a nice boost for the project, in terms of both morale and PR. Is anyone willing to help? 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

19 years, 5 months

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