Hi Robert:
How are you?
I think that putting a little generated file won´t hurt, notice that you could add a warning like
/* ========================================
this is a machine generated code modify xfile.l instead
========================================*/
I think that dealing with bison could make the build system a little more complex and remember that with the current one some people gets confused when starting. In fact lots of compilers source packages have both files in case you want to modify grammar rules the (.l .lex .y .ycc) and the .c in case you don´t have a parser generator, the gcc team does that and they are not the only ones, so seems to be a good choice.
Regards
Waldo Alvarez
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Robert Köpferl
Sent: Wed 12/1/2004 4:16 PM
To: ReactOS Development List
Subject: [ros-dev] Very bad Idea.
Sorry guys, but some of you never heared about (lets say) compiler and
code.
Never, never import generated artifacts into a VCS.
The only thing allowed is doc and code (models). At a generated peace of
code is not worked on (one mustn't). Instead one has to work on it's
model (its source). This sadly implies that the matching tool (a
compiler/transformer) must be available.
As you mentioned: People will start working on generated code (baaaad).
Also I hate projects where establishing a build env. seems like
programming an app. But you can't ascribe everything back to Gcc as a
minimum dominator. Gcc is not the high-level language to produce
parsers. Try to run a make script with gcc :-/
Thus I am for adding bison to our tool list and against importing
generated code (=not source). And think: Bison is litle more C++ affine
than a Pascal compiler or the like.
In my sight it's not harder than providing an archive which contains
bison beneath mingw etc.
If you want me to, I'd create that archive.
Steven Edwards wrote:
> Hi Alex,
>
> I understand everyones problem with bison and I agree with Filip,
> Casper and GvG. Importing the generated C file in to CVS is fine as far
> as I see it. The issue I worry about is people not submitting stuff
> back toi Winehq and having thier code get lost in the merges. I have
> some ideas about how to deal with this problem but I need to talk them
> over with GvG, Eric, Filip and others that have done a lot of work on
> ported Wine code.
>
> I have tried to address some of the other questions inline.
>
> --- Alex Ionescu <ionucu(a)videotron.ca> wrote:
>
>>All great points but I must ask, why should be bend our "rules" in
>>order
>>to be able to mingle cleanly with WINE, and why shouldn't they be the
>
>
>>ones that should also try to be more flexible. From what you're
>>saying
>>(I have no personal experience to base this upon), it seems that they
>>aren't trying very hard to make sure everything stays easily
>>portable. I
>>agree we need wine for the user dlls, but they also need our fixes to
>>be
>>easily implementable in their tree.
>
>
> The Wine developers spent a year looking in to how to implement MSI you
> would have come to the same answer they did and that was using bison to
> generate the database was the best way to go. This is a tool that is
> going to be used on Linux by Linux people for Linux people. I mean when
> you talk about porting Wine you have to understand that Winelib runs on
> Linux, Solaris, Mac OS/X. It does not get much more portable than that
> for a Unix application. And yes its audited vs MS_VC from time to time.
> I can build more of Wine with MS_VC than I can ReactOS.
>
> Most of the world still laughs at the ideal of ReactOS but Wine project
> (and Mingw) have been one of our closest supporters. A good number of
> the Wine developers lurk on this lists and try to do things to help
> both projects.
>
> If you give a example of a real problem we have had working with them
> so far then we can have that problem addressed in little to no time.
> The Wine development process is a little slow but its also for all the
> bad talk it gets one of the most stable and cleanest FreeSoftware
> projects there is. I have never checked out Wine CVS and had the build
> be broken, had a major regression that lasted more than a day or had
> any problem getting a good answer as to why something could not go in
> to CVS.
>
>
>>I think the best solution is for everyone to work together, and to
>>try
>>to respect our project's guidelines. If they really need to do stuff
>>their own way, we really need to do stuff our own way too. Maybe some
>
>
>>sort of mega conversion tool could be built or something of the sort.
>>I
>>think WINE has gotten really far, but because they are such an old
>>project, they are carrying a lot of cruft that needs to cleaned out
>>(just like any other project). It would be unsensical to have to
>>import
>>such cruft (I'm not referring to Bison, but those x-level DLL
>>messes).
>
>
> This is not going to happen overnight. If you look at the revision
> history of Wine you will see where Alexandre and the Wine team has
> added many things to aid in our development. Supporting seperating the
> Win16 and Win32 dlls in the build, adding cross-compiling support,
> cleaning up the header dependancy mess in the Wine tree, removing
> Wineisms/Unixisms etc....
>
> An import/conversion tool would be nice and GvG started working on
> making it a little less painful by adding support for Wine makefiles to
> the build system. Importing some of the other Wine tools would make
> things easy too such as WIDL and using the Wine headers but most of the
> ReactOS does not want to do that.
>
>
>>I don't see why the .C code would force everyone to use linux? Why
>>would
>>mingw32 not want to build it? Anyways, I restate, I'm against Bison
>
>
> Sure and I am not opposed to having the generated sources imported in
> the CVS. We already do this for the Wine Message Compiler that we have
> used in ntoskrnl and kernel32 for years.
>
> Anyway if anyone has any ideas about how to make code sharing with Wine
> more simple I am all ears. My patches to fix Wine building on MS_VC are
> almost never rejected, ditto for the Win16/32 cleanups or anything else
> that would make sharing code less of a pain.
>
> Thanks
> Steven
>
>
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - Helps protect you from nasty viruses.
> http://promotions.yahoo.com/new_mail
> _______________________________________________
> 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
Hi Ge:
Now that you talk it think that if some port is to be done that would be the ideal been a lot like the PC. IMHO the next could be a little endian well known arch.
Regards
Waldo
________________________________
From: ros-dev-bounces(a)reactos.com on behalf of Ge van Geldorp
Sent: Tue 11/30/2004 5:21 PM
To: 'ReactOS Development List'
Subject: [ros-dev] HAL reorganisation
As most of you know, I'm dabbling around a little bit with a port of ReactOS
to the Xbox. I think most of the differences between a standard PC and the
Xbox can be handled by using a custom HAL for the Xbox, after all, that's
what the HAL is for.
At the moment, we build 1 HAL, based on the value of MP in config it's
either a UniProcessor HAL or a MultiProcessor HAL. Which code is compiled is
based on preprocessor statements. I'd like to be able to build 3 HALs in
parallel, the UP, MP and Xbox HALs. When installing ("make install"), the
correct HAL would be selected based on the MP config var. When creating a
boot cd, all three would be copied to the CD and the setup program would
select the correct one to copy to the harddisk. This will allow us to build
a single boot CD for different configurations. I'm aware that we'll need a
NTKRNLMP.EXE on the boot CD too (I will try very very hard not to need a
different kernel for Xbox) for this "single boot CD" idea to work, but
that's a different problem and I'd like to tackle that later.
The three HALs will share a lot of the code. To avoid code duplication, I
propose to create a directory structure like this:
hal
|
--- hal
|
--- halx86
| |
| +----- generic
| | |
| | +----- include
| |
| +----- up
| |
| +----- mp
| |
| +----- xbox
|
+-- hal68k :-)
|
+-- etc...
The "generic" subdir will contain most of the code. The "up" subdir will
contain mostly simple .c files which just include a .c file from generic.
For example, the HalMakeBeep() function will be defined in generic/beep.c.
In "up" there will be a file beep_up.c which contains only 'include
"beep.c"', which will be compiled with the include path set to "../generic".
The "mp" and "xbox" directories can either include "generic" files or have
their own implementation of a given routine (e.g. display_xbox.c for
HalDisplay* functions on the Xbox).
Doing it this way we should have little code duplication and our dependency
tracking system should work.
Comments?
Gé van Geldorp.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
greatlrd(a)cvs.reactos.com wrote:
>CVSROOT: /CVS/ReactOS
>Module name: reactos
>Repository: reactos/lib/dinput/
>Changes by: greatlrd(a)mok.osexperts.com 04/12/01 07:20:14
>
>Added files:
> reactos/lib/dinput/: dinput.spec.def
>
>Log message:
> forget add file dinput.spec.def
> other wise dinput will not build
>
>
This is wrong and this file should be autogenerated. Only the
dinput.spec file should be in CVS!
- Filip
CXBX would not be suitable for developing ROS. CXBX doesn't try to emulate
any of the hardware of an Xbox, it instead tries to convert an xbox
executable (xbe) into a windows executable (exe). The conversion is done by
locating DirectX calls in the xbe (Note: On an xbox the executables are
directly linked to the DirectX libraries) and redirecting them appropriately
under windows.
-----Original Message-----
From: Richard Campbell [mailto:eek2121@comcast.net]
Sent: 01 December 2004 09:31
To: ReactOS Development List
Subject: Re: [ros-dev] HAL reorganisation
Keep in mind there is an XBOX emulator: CXBX available at
http://www.caustik.com/cxbx/, that, though incomplete, runs at least 1
commercial game and might be complete enough to run an xbox port of
ROS. Also, i'm sure you already know about the OpenXDK at
http://www.openxdk.org/.
weiden(a)cvs.reactos.com wrote:
> CVSROOT: /CVS/ReactOS
> Module name: reactos
> Repository: ./
> Changes by: weiden(a)mok.osexperts.com 04/11/30 12:21:34
>
> Modified files:
> ./: Makefile
>
> Log message:
> don't build msi for now as it uses a 3rd party build utility until situation is cleared
>
It build on a windows box, right? It worked on my wifes XP here,
but it did build right?
Ducken behind the desk waiting for more flamers,
James
Wow!
To complete the port for msi.dll, I need LoadTypeLib, RegisterTypeLib and
ITypeLib_Release. So, is stdole32 a "32 bit" replacement for Wine typelib
oleaut32 functions? I see only CreateTypeLib2 in the file.
Thanks,
James
ps.
I can compile msi w/o those functions, ha! just comment them out. So here
is a patch and makefiles, just remove the "msi-" and go.
Steven Edwards wrote:
> Hi Sam,
> --- Sam Lauber <sam124(a)operamail.com> wrote:
>
>>I tried it with MS mktyplib (with Wine DLLs). Strangly, it produced
>>the exact same FIXMEs that the C program generated, but generated a
>>diffrent typelib. And more then two bytes differed. The two typelibs
>>are attached. I'll try it with InstallShield.
>
>
> Try this one
>
> http://www.volny.cz/xnavara/stdole32.c
>
> Thanks
> Steven
>
>
Only in /root/wine/wine/dlls/msi: .cvsignore
Only in /root/wine/wine/dlls/msi: CVS
Only in ./: Makefile
Only in ./: Makefile.ros-template
diff -u /root/wine/wine/dlls/msi/action.c ./action.c
--- /root/wine/wine/dlls/msi/action.c 2004-10-27 20:43:05.000000000 -0500
+++ ./action.c 2004-10-30 12:14:17.000000000 -0500
@@ -28,6 +28,7 @@
#include <stdarg.h>
#include <stdio.h>
+#include <fcntl.h>
#define COBJMACROS
@@ -39,7 +40,7 @@
#include "fdi.h"
#include "msi.h"
#include "msiquery.h"
-#include "msvcrt/fcntl.h"
+//#include "msvcrt/fcntl.h"
#include "objbase.h"
#include "objidl.h"
#include "msipriv.h"
@@ -3477,7 +3478,7 @@
continue;
}
- res = LoadTypeLib(package->files[index].TargetPath,&ptLib);
+// res = LoadTypeLib(package->files[index].TargetPath,&ptLib);
if (SUCCEEDED(res))
{
WCHAR help[MAX_PATH];
@@ -3488,7 +3489,7 @@
resolve_folder(package,helpid,help,FALSE,FALSE,NULL);
- res = RegisterTypeLib(ptLib,package->files[index].TargetPath,help);
+// res = RegisterTypeLib(ptLib,package->files[index].TargetPath,help);
if (!SUCCEEDED(res))
ERR("Failed to register type library %s\n",
debugstr_w(package->files[index].TargetPath));
@@ -3503,8 +3504,9 @@
debugstr_w(package->files[index].TargetPath));
}
- if (ptLib)
- ITypeLib_Release(ptLib);
+ if (ptLib){
+ //ITypeLib_Release(ptLib);
+ }
}
else
ERR("Failed to load type library %s\n",
Only in ./: patch.diff
diff -u /root/wine/wine/dlls/msi/suminfo.c ./suminfo.c
--- /root/wine/wine/dlls/msi/suminfo.c 2004-10-18 13:20:12.000000000 -0500
+++ ./suminfo.c 2004-10-30 00:09:12.000000000 -0500
@@ -23,6 +23,8 @@
#define COBJMACROS
#define NONAMELESSUNION
+#define PRSPEC_PROPID (1)
+
#include "windef.h"
#include "winbase.h"
#include "winreg.h"
# $Id: Makefile,v 1.12 2004/02/25 20:00:41 sedwards Exp $
PATH_TO_TOP = ../..
TARGET_TYPE = winedll
include $(PATH_TO_TOP)/rules.mak
include $(TOOLS_PATH)/helper.mk
# $Id: Makefile.ros-template
TARGET_NAME = msi
TARGET_OBJECTS = @C_SRCS@ @EXTRA_OBJS@
TARGET_CFLAGS = -D__REACTOS__ @EXTRADEFS@
TARGET_SDKLIBS = @IMPORTS@ libwine.a wine_uuid.a ntdll.a
TARGET_BASE = $(TARGET_BASE_LIB_WINMM)
TARGET_RC_SRCS = @RC_SRCS@
TARGET_RC_BINSRC = @RC_BINSRC@
TARGET_RC_BINARIES = @RC_BINARIES@
TARGET_CLEAN = *.tab.c *.tab.h
default: all
DEP_OBJECTS = $(TARGET_OBJECTS)
include $(TOOLS_PATH)/depend.mk
#
# Bison is requiered for building msi.dll. If MingW32 for windows,
# download bison from http://gnuwin32.sourceforge.net/
# Make sure bison.exe is placed in your command path for execution.
#
#
sql.tab.c sql.tab.h: sql.y
bison -p SQL_ -d ./sql.y -o sql.tab.c
cond.tab.c cond.tab.h: cond.y
bison -p COND_ -d ./cond.y -o cond.tab.c
Hi,
Just like to let you know that the latest cvs code does not compile out of the
box using mingw on a debian testing box.
$i586-mingw32msvc-cc --version
i586-mingw32msvc-cc (GCC) 3.4.2 (mingw-special)
The problem is some functions are re-declared in the string.h (line 169,
wchar_t() ) and stdio.h (line 269, putwc() )files. Also the loadlib.c test
file failed to compile since it was not including stdlib.h and could not find
the mbstowcs function.
This is the latest cvs code from 5:30'ish GMT.
Cheers,
Damian
output from cvs diff:
Index: apps/testsets/loadlib/loadlib.c
===================================================================
RCS file: /CVS/ReactOS/reactos/apps/testsets/loadlib/loadlib.c,v
retrieving revision 1.2
diff -r1.2 loadlib.c
26a27
> #include <stdlib.h>
Index: include/msvcrt/stdio.h
===================================================================
RCS file: /CVS/ReactOS/reactos/include/msvcrt/stdio.h,v
retrieving revision 1.8
diff -r1.8 stdio.h
269c269
< int putwc(wint_t wc, FILE* fileWrite);
---
> //int putwc(wint_t wc, FILE* fileWrite);
Index: include/msvcrt/string.h
===================================================================
RCS file: /CVS/ReactOS/reactos/include/msvcrt/string.h,v
retrieving revision 1.6
diff -r1.6 string.h
169c169
< wchar_t* wcsdup(const wchar_t* wsToDuplicate);
---
> //wchar_t* wcsdup(const wchar_t* wsToDuplicate);
Hay!!!!
greatlrd(a)cvs.reactos.com wrote:
> CVSROOT: /CVS/ReactOS
> Module name: reactos
> Repository: reactos/include/
> Changes by: greatlrd(a)mok.osexperts.com 04/11/28 16:15:24
>
> Added files:
> reactos/include/: dinput.h
>
> Log message:
> first port of wine directx support to reactos
I want to commit my port of msi.dll from wine!
8^)
James
PD: Humm, send me a contact mail and i will send you
the files ziped.
Best Regards,
Lucio Diaz
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es
Could Someone with autorization to edit the
Reactos.com Web page look at my FAQ and Howto, to
decide if he/she likes it and what have to be changed
so it could be in the web page.
I think it is a improvement over the actual texts. The
texts i did are thought for everybody, even with
screenshots to guide the people with little
experience.
Thankyou,
Lucio Diaz.
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es
>While attempting to guess the location isn't going to
>be successful
>100%
>of the time, it would probably be better then the 99%
>incorrect that
>you
>get with always defaulting to 1 set zone.
>Also, are there any other user-set preferences that
>come before the
>date/time page (How do you call the different parts
of >Setup?) that
>might help determining location?
It seems a pain in the @ss to code the whole thing,
taking in acount ALL the countries and their probable
timezones(countries with diferent timezone areas) for
something as easy to the user as to look at his watch
and set the time. I dont mind what standard (if GMT -8
or GMT 0) you chose, but i believe that making it more
elaborate does not worth today when many other things,
quite more important, are waiting to be implemented
(like Networking). I am sure that time will come for
those details.
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es
Hi!
I have written a tool to configure the ReactOS source tree (customize
the build) It builds a GUI interface from an XML file which lists all
the possible options and how they are "realized" (in which file a value
has to be changed to make the build-system do what is wanted, i.e. set
KDBG in config to 1)
I would like to add the possibility of configuring things like
WHOLE_PAGE_ALLOCATIONS or TAG_STATISTICS_TRACKING (from ntoskrnl/mm/npool.c)
It would be good if such defines were moved into a file like
ntoskrnl/include/config.h which is then included by ntoskrnl.h and looks
like this:
/* Enable tracking of statistics about the tagged blocks in the pool */
#undef TAG_STATISTICS_TRACKING
/*
* Put each block in its own range of pages and position the block at the
* end of the range so any accesses beyond the end of block are to invalid
* memory locations.
*/
#undef WHOLE_PAGE_ALLOCATIONS
I don't want to make the tool edit the C files directly.
If anybody is against this please let me know, otherwise I will do it.
(Note: The tool is written in python and will thus not be allowed into
the reactos tree but I will provide it for whomever is interested)
Thanks,
blight
>The most intelligent solution is to stick to GMT 0.
>Best regards,
>Alex Ionescu
I agree, is both the easier and the most logic option
(also i live at GMT 0 ;)
______________________________________________
Renovamos el Correo Yahoo!: ¡100 MB GRATIS!
Nuevos servicios, más seguridad
http://correo.yahoo.es
Hi Hartmut!
You have changed the w32 callback to save the FPU state, this is wrong I
think!
I was wondering too wether it should be saved so GvG suggested to check
myself and I modified our winhello app...
It prints out the FPU control word, calls CreateWindow and printf the
FPU control word again.
In the callback for the WM_CREATE message (produced by CreateWindow) it
also prints the control word, then modifies it (and prints the modified one)
This is the output on windows2000:
Original FPU control word: 0x8001f
WM_CREATE: Original FPU control word: 0x8001f
WM_CREATE: Modified FPU control word: 0xa001f
FPU control word after CreateWindow: 0xa001f
Of course I have attached the program.
I am not sure but I think in the KiClearFloatingPointState which you
have added you have to set KPCR->NpxThread to NULL if it's CurrentThread
before you do the fn/xsave because it could raise a delayed FPU
exception (which will be ignored when KPCR->CurrentThread is NULL and be
delivered when the saved FPU state is restored for the thread)
I think I have made the same mistake in tskswitch.S - I am pretty sure
it has to be fixed there because we don't want a FPU exception to be
raised while we are in a cli/sti block and switching to another task.
- blight
Hi Thomas:
There are some parts of your e-mail that I can't understand but I believe you try to give some kind of solution. And yes I think is correct at some point, I was wondering once about that, to do the same with native applications as for example what is done with java applets running in the browser. Containing them to some set of files. I think that yes it would be good to prevent applications corrupting other files and such things. And in fact could be great for advanced users But ...
1 - That is not a solution for viruses, there are kernel mode virus and trojans I wonder how that can get there. At the end human intelligence can't be stopped that easy and of course the opposite also happens, ignorance could be huge. I wonder how a virus like the I love you that can be written in a couple of minutes could spread that far. Believe me that won't work.
2 - That should not be enabled by default, sometimes if you present a password to users they will get lost. That happened to some users that switched from win98 to an NT based one. That was news, and was true. With the solution you propose there will be a lot that will press the Yes. Eh I even know ppl that click whatever they please when a message box appears.
Regards
Waldo
________________________________
De: ros-dev-bounces(a)reactos.com en nombre de Thomas Larsen
Enviado el: jue 11/25/2004 12:42
Para: ReactOS Development List
Asunto: RE: [ros-dev] ReactOS and Viruses
Hi why would it be a could a idea simply becures we eliminate a lot of old viruses but we could
allso make a function theire hold all exe files from execute when they contain some strange
command f.eks the delete or format funtion or some other stuff or some kind of database and the
send a signal out
Maybe
Reactos->MaybeVirusFile(Filename,Path);
VirusApps<-TestingFile(Filename,Path);
Ekstra Idea:
And a funtion to Stop new apps from run (REGEDIT RUNAPPS etc.)
Some New viruses use that way to start all the time and the user could be asked
NEW APP STARTING UP
RUN THE APP [X] DISMISS THE APP [ ] VIRUS TEST APP [ ]
Information about file
NEWER SHOW AGAIN [X]
And then make a group of apps that run i secure mode FOLDER SECURERUN
and then make a group of apps that run i unsecure mode FOLDER UNSECURERUN
So those in SECURE can´t change the reg and delete file e.g.
don´t know just and idea
but think people should care more about getting reactos to work...
Thomas
>>Hi Rick:
>Well I don't believe that would be a protection at all against viruses. Why?
>If I where to write a virus and knowing that reactos has such protection that would not stop me
at
>all. I could simply write a function to calculate the hash in the virus (or simply tell the OS to
>do it for me) and update such database. Look at windows file protection, virus laugh at it. I
>think the verification of the PE checksum is enough to tell if a file is corrupt and would be
>faster
>wich means a faster load. If you want to know some more about viruses look for the e-zines of 29A
>on the internet to find out more about the subject. Their articles are as advanced as those in
Waldo
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev
Please add the following files to the bootcd:
lib\dnsapi\dnsapi.dll 1
lib\iphlpapi\iphlpapi.dll 1
lib\rpcrt4\rpcrt4.dll 1
lib\ole32\ole32.dll 1
This fixes the reboot loop FloFri was seeing with current cvs bootcds.
(ntuser/desktop.c:499) CreateDesktop: Screen-Saver
(NTDLL:ldr/utils.c:2018) Failed to create or open dll section of
'dnsapi.dll' (Status c0000135)
(NTDLL:ldr/utils.c:1357) failed to load dnsapi.dll
(NTDLL:ldr/utils.c:1819) failed to load dnsapi.dll
(NTDLL:ldr/utils.c:2085) LdrFixupImports failed for ws2_32.dll, status=c0000135
(NTDLL:ldr/utils.c:1357) failed to load ws2_32.dll
(NTDLL:ldr/utils.c:1819) failed to load ws2_32.dll
(NTDLL:ldr/utils.c:2085) LdrFixupImports failed for iphlpapi.dll,
status=c0000135
(NTDLL:ldr/utils.c:1357) failed to load iphlpapi.dll
(NTDLL:ldr/utils.c:1819) failed to load iphlpapi.dll
(NTDLL:ldr/utils.c:2085) LdrFixupImports failed for rpcrt4.dll, status=c0000135
(NTDLL:ldr/utils.c:1357) failed to load rpcrt4.dll
(NTDLL:ldr/utils.c:1819) failed to load rpcrt4.dll
(NTDLL:ldr/utils.c:2085) LdrFixupImports failed for ole32.dll, status=c0000135
(NTDLL:ldr/utils.c:1357) failed to load ole32.dll
(NTDLL:ldr/utils.c:1819) failed to load ole32.dll
(NTDLL:ldr/utils.c:1941) LdrFixupImports() failed for setup.exe
(NTDLL:ldr/startup.c:441) Failed to initialize image
--
The cheese stands alone.
Hi Gregor,
I've some problems with your changes. On my smp machine I get an assertion
from fpu.c line 452. I think, it isn't possible to use
KPCR.PrcbData.NpxThread on a smp machine. With your first patch I don't have
any problems.
- Hartmut
Hi got a problem i Reactos
The Kernel32.Def File
LIBERY KERNEL32.DLL
EXPORTS
NTDLL.RTLALLOCHEAP
And all the other def files where HAL.Somefunction NTDLL.Somefunction etc are in
I know that NTDLL.DLL IMPORTS "RtlAllocateHeap etc." those funktions from a lib in rtl.lib but
don�t know if thats the
problem becures SCSIPORT.SYS allso import some HAL.somefunction witch allso are broke
The tool DependX86 a tool use to find broke link in files can�t either find them and it a littel
strange problem becures i should work microsoft allso do that kind of linking against files and
allso use lib files to import
Use the most recent CVS of Reactos and the newest edition of MingGW
Allso tried differet option and differt compilere versions but seems to me theire must lay a
strange problem in reactos og MingGw Simpl don�t support that...
Crashlist of Files:
Kernel32.dll depend on NTdll.dll
User32.dll depend on kernel32.dll
Atapi.sys depend on Scsiport.sys depend on HAL.DLL
The Subsystem CRSS
And Many more
Anybody Help Me Please
Thomas
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - What will yours do?
http://my.yahoo.com
Hi Rick:
Well I don't believe that would be a protection at all against viruses. Why?
If I where to write a virus and knowing that reactos has such protection that would not stop me at all. I could simply write a function to calculate the hash in the virus (or simply tell the OS to do it for me) and update such database. Look at windows file protection, virus laugh at it. I think the verification of the PE checksum is enough to tell if a file is corrupt and would be faster wich means a faster load. If you want to know some more about viruses look for the e-zines of 29A on the internet to find out more about the subject. Their articles are as advanced as those in phrack (the latest). I think there is not solution for viruses, users will always do insecure things and viruses will be there waiting for them to do it.
Regards
Waldo
________________________________
De: ros-dev-bounces(a)reactos.com en nombre de Rick Langschultz
Enviado el: Lun 11/22/2004 11:25 p.m.
Para: ReactOS Development List
Asunto: [ros-dev] ReactOS and Viruses
Sun will be releasing Solaris 10 shortly as a commercial product available for purchase. There is a new file system that is 128-bit, and is protected by md5 checksums, I think this is a great idea for reactos. I think before a program executes there should be a binary verifier that checks this checksum and then allows the program to run. This would help in deterring Windows viruses from attaching themselves to reactos binaries. Since ReactOS is open source it will be harder to protect a binary if there is an attack and a malicious user replaces a dll or an exe. Perhaps this can be done using a small xml file or a txt file called md5sums or something. Please let me know what you think.
I noticed yesterday while installing ros from a locally generated
bootcd that pcnet.sys is not included. Could someone add it to
reactos.dff? Thanks!
Andrew
--
The cheese stands alone.
Sun will be releasing Solaris 10 shortly as a commercial product
available for purchase. There is a new file system that is 128-bit, and
is protected by md5 checksums, I think this is a great idea for reactos.
I think before a program executes there should be a binary verifier that
checks this checksum and then allows the program to run. This would help
in deterring Windows viruses from attaching themselves to reactos
binaries. Since ReactOS is open source it will be harder to protect a
binary if there is an attack and a malicious user replaces a dll or an
exe. Perhaps this can be done using a small xml file or a txt file
called md5sums or something. Please let me know what you think.