For those of you who have heard nothing of my plans to write a RosFS
service for ReactOS, here are some details about my plan.
RosFS
RosFS is a small service running on system initialization by default
that indexes files, folders, users, devices, and network resources can
hold metadata via MySQL, sleepycat DB, TCL, Apache, and Perl; which will
all be embedded within the service itself. RosFS will hold encrypted
resources based off of a key that is created with the first startup of
ReactOS, it changes every 30 days to ensure security. The RosFS can be
accessed online via the built in web server with can be an encrypted
connection - SSL, or TLS. User ACLs can be set on a machine level or a
domain level. RosFS will support a SQL-like querying language that can
be written easily - it will have triggers, procedures, functions, and
saved queries - which are all logged. Triggers will be supplied by a
TCL-like language with features of Perl. An service will provide users
with current system updates, patches, etc stored on a domain server -
this option will only be installed on a powerful server with pretty good
hardware - ie: not for home use!!!
A few problems I know that will arise in developing such a project are:
1) Size
2) Security
3) Where to keep the files on the system
4) The RosFS query language will be trouble to write and maintain
depending on if a user uses such Databases like ORACLE, MySQL, MSSQL,
etc.
5) Explorer Integration - Will Explorer.exe need to be rewritten to
allow the addition of Metadata structures, etc.
6) Web integration - Perl, PHP, TCL, CGI, ISAPI???
Please send me comments and concerns about the RosFS project.
Hi All and GreatLord,
I just tested Starseige Tribes under ReactOS and it does load. You need
dsound.dll and dinput.dll from Wine. GreatLord is working on fixing
these to work under Windows and ReactOS now. If you want to test it
tribes is a free download you just may need to do a google search. Make
sure you set the graphics to GDI under Windows and then copy your
config over. Of course the mouse wont work under ReactOS until
GreatLord is done with his dinput changes. I have not tested with
ReactOS new direct input as I am short on time tonight. I will try that
tommrow.
Thanks
Steven
__________________________________
Do you Yahoo!?
Meet the all-new My Yahoo! - Try it today!
http://my.yahoo.com
Hi All!
Jim Tabor wrote:
> CVSROOT: /CVS/ReactOS
> Module name: reactos
> Repository: reactos/lib/msi/
> Changes by: jimtabor(a)mok.osexperts.com 04/11/30 11:10:55
>
> Added files:
> reactos/lib/msi/: .cvsignore Makefile Makefile.in
> Makefile.ros-template action.c cond.y create.c
> distinct.c handle.c insert.c msi.c msi.spec
> msipriv.h msiquery.c order.c package.c query.h
> record.c regsvr.c select.c sql.y string.c
> suminfo.c table.c tokenize.c update.c
> version.rc where.c winehq2ros.patch
>
> Log message:
> First port of Wine projects msi.dll
>
With this commit, we will be using bison to build cond.y and sql.y.
Okay, for those using a Window 32 based system 8^p you will need
*bison*!
http://gnuwin32.sourceforge.net/packages/bison.htmhttp://www.mingw.org
Good luck,
James
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.
Hi,
I have started coding the Direct3d 9 dll. It isn't something usable yet, but
only a few kernel calls have to be made to run the first (very simple)
Direct3D program. I have already looked up those functions, but most of them
need some huge structs as parameters.
At the moment I don't have the time to work on it. Maybe one of you would
like to do so. But be warned this is the first time that i am working on an
open source project and my coding style isn't the best.
Maarten Bosma
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