patchworks
Content Type
Profiles
Forums
Events
Posts posted by patchworks
-
-
-
Given that I am NOT a developer (much less a Kernel one), couldn't ReactOS core components be (easily?) "ported" instead of reimplementing everything from scratch?
0 -
Check this (cool) open source tool: https://github.com/valinet/ExplorerPatcher
1 -
Suggestion: Sonic Foundry's Vegas (if I remember well up to 5 version)...
0 -
The best way is to ask hardware manufacturers to fund the project, IMHO; Lenovo, for example, could be interested...
0 -
The ReactOS ®evolution has begun!
During the last couple of months we have been compiling all your feedback and suggestions about ReactOS in order to come up with a new paradigm. Now the time has come to show you what we've been working on: ReactOS Community Edition.
ReactOS Community Edition is.. special, not just as a form of connecting further with our Community, it also opens doors to new ideas and strategies.
We hope that you like all the work that we've done as we got inspired by a lot of your ideas. The is the product of that inspiration.
Discover all the details of the ®evolution at the community site and join us at Indiegogo to show your support.
A ®evolution can only happen when we all push things, together. Please help by backing, spreading the word, providing feedback... Every bit counts.
Microsoft is not the only one //build/ing new things this year. We have something up our sleeves as well!Official website: http://www.reactos.org/
0 -
The ReactOS Project is pleased to announce the release of version 0.3.16. A little under a year has passed since the previous release and a significant amount of progress has been made. Some of the most significant include completion of the CSRSS rewrite and the first stages of a shell32 rewrite. 0.3.16 is in many ways a prelude to several new features that will provide a noticeable enhancement to user visible functionality. A preview can be seen in the form of theme support, which while disabled by default can be turned on to demonstrate the Lautus theme developed by community member Maciej Janiszewki. Another user visible change is a new network card driver for the RTL8139, allowing ReactOS to support newer versions of QEMU out of the box.
Official website: http://www.reactos.org/
Download: http://www.reactos.org/download-reactos
Changelog: http://www.reactos.org/wiki/ChangeLog-0.3.16
Enjoy !
0 -
Summary
We provide a free driver as well as a C++ software library for cameras that comply with the 1394 Digital Camera Specification as published by the 1394 Trade Association www.1394ta.org. It is a fast, easy way to gain direct access to camera imagery and direct control of camera features.
Features
- Distribution
- using the Nullsoft Scriptable Install System
- Includes the option to automatically install the CMU driver for all presently-connected cameras
- Includes the option to install debug versions of the DLL and Demo App
[*]API overhaul for the 6.4 release series includes:
- Complete rework of the C1394Camera and associated class interfaces against better Object-Oriented Design Principles (encapsulation and data-hiding).
- Migrated toward strong Model-Controller-View separation of concerns: (1394cmdr.sys-1394camera.dll-1394CameraDemo.exe).
- Complete (if partially untested) implementation of IIDC DCAM version 1.31, including:
- 1394b support
- Optional Functions (PIO,SIO,Strobe)
- Note: Format 6 (Stored Image) is still being ignored (does a camera even exist that supports this?).
- 1394b support
[*]Behavioral Changes
- No more kernel-side frame timeouts. Previously, a frame buffer would simply detach itself after ten seconds, causing trouble for low frame rates and/or infrequent triggering.
- OneShot and MultiShot functionality are now meaningfully exposed (see the documentation for CAM_ACQ_START_VIDEO_STREAM for details)
- You may now stream the camera data to multiple PC's on the same 1394 bus (see the documentation for CAM_ACQ_SUBSCRIBE_ONLY for details).
[*]Documentation
- Uses Doxygen to generate 1394camera.chm, which is installed with the rest of the driver set.
- using the Nullsoft Scriptable Install System
Hardware Requirements
This driver set should work with all versions of MS Windows from 98 SE through XP. Beyond that, there are no hard minimums other than a 1394 host controller (preferably OHCI-compliant) and a compliant camera. However, the things that you can do with the data from these cameras will be limited by how much RAM you have and how fast your processer is, so more of both will be better. Don't expect useful results on anything less than a Pentium II 233 with 64 MB of RAM.
0 - Distribution
-
Just discovered it, hope that helps:
UWIN allows UNIX applications to be built and run on Microsoft Windows 7, Vista, XP, 2000, NT, ME, 98, 95 (W7/VI/XP/2K/NT/ME/98/95) with few, if any, changes necessary. UWIN source and binaries are available under the open source at AT&T AST/UWIN open source downloads.UWIN contains:
- Libraries that emulate a UNIX environment by implementing the UNIX Application Programming Interface (API)
- Include files and development tools such as cc(1), yacc(1), lex(1), and make(1).
- ksh(1) (the Korn Shell) and over 250 utilities such as ls(1), sed(1), cp(1), stty(1), etc.
Most of the UNIX API is implemented by the POSIX.DLL dynamically loaded (shared) library. Programs linked with POSIX.DLL run under the WIN32 subsystem instead of the POSIX subsystem, so programs can freely intermix UNIX and WIN32 library calls. A cc(1) command is provided to compile and link programs for UWIN on Windows using traditional UNIX build tools such as make(1). The cc(1) command is a front end the the underlying compiler that performs the actual compilation and linking. It can be used with the Microsoft Visual C/C++ 5.X compiler, the Visual C/C++ 6.X compiler, the Visual C/C++ 7.X compiler, the Digital Mars C/C++ compiler, compiler, the Borland C/C++ compiler, and the Mingw compiler. The GNU compiler and development tools are also available for download to UWIN.
UWIN runs best on Windows W7/VI/XP/NT/2000 with NTFS, but will run in degraded mode with the FAT file system, and further degradation with Windows ME/98/95.
0 - Libraries that emulate a UNIX environment by implementing the UNIX Application Programming Interface (API)
-
OK, this is a related-news that could be interesting for both projects:
Commit by cgutman :: r55555 reactos/ (144 files in 45 dirs): (link)[uSB]
- We proudly merge the first charge of the usb-bringup branch. We do want to stress hardware support is still under heavy development and testing in real hardware is experimental
- Merge the Human Interface Device Stack(HID) which is used for mice / keyboards and other devices which use the USB interface, consisting of hidusb, hidparse, hidclass, mouhid, kbdhid
- Merge the composite driver, supports USB composite devices, laid out in usbccgp
- Merge the generic hub driver, which supports the USB root hub and in future USB hubs. Driver is usbhub
- Merge the Open Host Controller Interface driver (ohci)
- Merge the Enhanced Host Controller Interface driver (ehci)
- Merge the many fixes in other areas of ReactOS needed for USB to work (ntoskrnl, pci, inf, umpnpmgr, usetup)
- Special thanks goes the Haiku team, whose excellent code has provided a great base for the development of the new ReactOS USB / HID stack
- The development of the USB stack has shown the great potential when ReactOS developers team up together to achieve a common goal. The involved developers are here, listed alphabetically: Alex Ionescu Amine Khaldi Cameron Gutman Johannes Anderwald Michel Martin Thomas Faber Thomas Lotz(Haiku) Let's start the ReactOS revolution
Hope that helps, or at least inspires !
0 - We proudly merge the first charge of the usb-bringup branch. We do want to stress hardware support is still under heavy development and testing in real hardware is experimental
-
Just found this interesting article:
There are quite a few XP to Windows 7 transformation packs are available, but to be frank, those packs will slow down your Windows significantly. If you really want to get Windows 7 look, then download and use the below shell pack and also don’t forget to use Windows 7 theme for XP.http://www.intowindows.com/download-exact-windows-7-shell32-for-xp/
Dunno if it's possible to do the same for Kex'd 98, btw hope that inspires !
0 -
I just discovered that IBM released (the source code of their Workplace Shell for Windows:
Workplace Shell for Windows is a shell replacement program for WIN-OS/2 and Windows v3.1 which provides admins the same user interface in their Windows environments as is available in their OS/2 desktop. It replaces the default Windows shell program (PROGMAN) with an "OS2 Workplace Shell"-like user interface and features.This software was last updated and released in 1995. But, due to continued requests for new features or enhancements from sysadmins and end users that are still using this software, I have decided (with IBM's permission) to release the WPSFWIN software source code base and build scripts (wpsfwin-build-source.zip). Now users can rebuild WPSFWIN shell to enhance or add features as they desire.
Source code has been released under a proprietary "Workplace Shell For Windows" Public License - v 1.0
Togheter with BeOSWin (attached - public domain ? - sources), could be a good base for an alternative open source shell for Win 9x, IMHO.
Hope that helps, or at least inspires !
0 -
Dunno if anyone already knows it (search gives no matches), btw it seems very interesting:
Explorer++ is a free multi-tab file manager for Windows (C++ / GPL v3).Available on Windows XP and above, it features the same familiar interface as Windows Explorer, while introducing several enhancements and improvements for a much richer file browsing experience.
Features:
- With the option to save to the registry or a configuration file, Explorer++ is completely portable.
- Tabbed browsing for easy management of multiple folders.
- Display window shows previews of files as they are selected.
- Easy-to-remember keyboard shortcuts for quick navigation.
- Customizable user interface.
- Full drag-and-drop support with other applications, including Windows Explorer.
- Advanced file operations such as merging and splitting supported.
Hope that inspires !
0 - With the option to save to the registry or a configuration file, Explorer++ is completely portable.
-
I tested W7/64 and honestly i don't like it, so do you think it's possible to "port" the better things from Win7/64 to XP64 to revive it ?
0 -
From I, Hacker (on December 27, 2009):
Alky PostmortemA lot of people have asked me what happened to the Alky project. The short answer is that we made a lot of bad business moves, but that answer glances over a lot of the fun little details. Having gained considerable knowledge from other stories of failed startups, I figure I'll throw one of my own into the ring.
History
The Alky project's history can be split into a few phases:
Conception
Alky began as an experiment to see how easily I could convert Windows PE files to run natively on Mac OS X (x86). If it were to work, it may make it possible for me to convert Windows games to run natively on OS X, which was my primary focus. I started by writing a converter that ripped the segments out of the original file and throw them into a Mach-O binary, then linking it against 'libalky'.
LibAlky was a reimplementation of the Win32 API. At first, I tested with files that just called a few simple things, like user32:MessageBoxA, and it worked spectacularly. It was at this point that I realized the basic concept was not only sound, it made a whole lot of sense.
Actual project creation
Once the initial prototype worked, it was time to get people interested. I went to Michael Robertson (who was my employer at the time) and gave him a rundown. He offered to buy the domain, host the project, and get some resources behind it, primarily PR-wise. Within a few days, the project started actually feeling real. We got the site up, wrote some copy to explain what we were doing, and then put it out on Slashdot.
Unsurprisingly, we received three types of responses:
- This is impossible, it simply can't work from a technical point of view. (This was especially hilarious coming from a Transitive engineer, considering that what they did is considerably more complicated.)
- This is possible, but it won't happen due to the immense amount of work involved. (Half right -- more on this later.)
- Wine sucks, I hope you guys can do it better. (We couldn't -- more on this later.)
But more importantly than anything else, we got some developers involved. However, they ended up being driven away.
Mismanagement of the open source project
Alky was the first open source project I'd ever managed that consisted of more than myself and a few friends, and as a result it was mismanaged at every possible turn. It was unclear what people should've been working on, no effort was made to document the project, and no real effort was made to include the developers that were so interested in working on the project.
This was compounded by a rewrite and redesign, which I decided (foolishly) to take on entirely by myself. Some of the design was done as a group, but none of it ever left my hard drive, so work stalled on the existing codebase and the project started to wither.
Shortly thereafter, Falling Leaf Systems was incorporated to back the development of Alky. This further increased the rift between the open source developers and the "core" group (consisting of myself and one of the cofounders of the company). Originally, we planned to dual-license the codebase, but as we got more into discussions of the goals of the business, it became clear that closing the source was the right move. However, we couldn't have picked a poorer way to do it.
Rather than be upfront about the move to closing the source, we simply killed the IRC channel and took down the site. The open source developers were left wondering what happened, while we moved on the rewrite.
Prey and the Sapling Program
Alky was completely rewritten with the new design, and work quickly moved forward on getting the first game running. We released a converter for the demo of Prey (Mac OS X only at first), as part of our new Sapling Program. The Sapling Program was created as a way to get some upfront money for the company, so we could get needed hardware, go to the GDC (which was a horrendous waste of money, for the record), etc. We sold memberships for $50, which gained access to the Prey converter and all future converters. Of course, after we finished Prey for Linux, there were no more converters.
Loss of focus
After Prey was done, we'd planned on implementing DirectX 9 with hopes of running Oblivion, but we lost sight of this goal. Instead, we decided to go after DirectX 10. Along with this shift in focus came an even bigger one: we were no longer targeting Mac OS X and Linux primarily, but Windows XP. We saw that Vista was tanking, and DirectX 10 was only available there, so we decided that we only had a limited window to make money off of that.
Shortly after we made the change, we released a library to allow a few of the DX10 SDK demos to run on Windows XP via OpenGL, albeit with serious missing features (e.g. no shaders). It got some attention, but few people were able to actually get it working. After this was out, I started work on reverse-engineering the shader format and writing a recompiler that would allow Direct3D 10 shaders to work with OpenGL, and even more importantly, without DX10-class hardware. Geometry shaders were planned to run on the CPU if the hardware wasn't available to handle it, and work progressed quickly.
Alky for Applications
We discovered a project known as VAIO to allow Vista applications (non-DX10) to run on Windows XP, and after some talks with the developers, they (or more specifically, one of them -- we'll call him Joe) were sucked into Falling Leaf. We rebranded VAIO and it was released as Alky for Applications. After this, Joe was tasked with making Halo 2 and Shadowrun -- Vista-exclusive but non-DX10 games -- run on Windows XP. We were so confident in our ability to do this, we set up an Amazon referral system and made it such that anyone who purchased either game through us would get a copy of the converter for free.
At this point, I was working heavily on DX10 stuff, and was under tight deadlines to show things off to a company that was interested in our technology, but the clock was ticking. About a week before the planned release of the Halo 2 and Shadowrun compatibility system, Joe came to us and told us that he'd not been able to get anything working, and had very little to show for the time spent. In retrospect, it was my fault for not checking up on him (my job as his manager), but at that point it just made me realize there was no way it was going to be done in time.
I picked it up -- dropping DX10 in the process -- and attempted, feebly, to get it done. Of course, I picked the most difficult way to approach it; reverse-engineering the Windows application compatibility system. By the time I got anything remotely close to working, we'd already missed our deadlines for both the DX10 work and the Halo 2/Shadowrun converter.
The death of Falling Leaf
After all this went down, I fell into a bit of a depression. I became demoralized to the point of just not wanting to go on anymore, in the face of repeated failures, very much in public. Despite us not walking away with a dime -- we made approximately $7000 in total, none of which went to any of the founders of the company -- I felt that we'd ripped people off, despite the best of intentions. It wasn't long after this that Brian (one of my co-founders) stepped down as CEO, and I closed the doors on the company. The source to Alky and Philosopher (the compiler framework used in the shader work) were released at the same time.
Lessons Learned
- If you're going to run an open source project, make it easy for people to contribute. Not only that, make it worthwhile for them to contribute and make them a part of the project, not just free workers.
- If you're going to kill an open source project, be up front with the people involved. It's not only dishonest not to do so, you lose people who may well go to bat for you even if you are commercial. This is especially important for a project like Alky, where we faced nearly universal negativity.
- If you're going to change focus, be clear with your users as to what's going on, and make sure you make it clear that the old stuff is dead and gone. If you don't, you come off looking terrible in the press, and it just makes you look like amateurs (which we were).
- Make sure your employees are actually doing what they're supposed to be doing, especially if they're working remotely. This was really the final nail in the coffin for Falling Leaf.
Alky Reborn
Now, with all of that said, there's a light at the end of the tunnel perhaps. The source for Alky has been pulled into Github and it seems that development is picking up again. Perhaps I can shed some light into what design decisions were made, how it was implemented, and how I'd do it now if I were so inclined. I don't plan on working on Alky again (that time has passed), but I'd still love to see it succeed.
The old Alky design
Alky's original prototype had a very simple design, library-wise. There was one big LibAlky which contained all of the Win32 API implementations, each talking directly to native APIs. This design very quickly became unworkable, as we had tons of duplicated, unmaintainable code.
The new Alky design
Alky was redesigned such that we had the Nucleus and the Win32 APIs. The Nucleus was intended to abstract away the platform-specific details and expose a universal API that the Win32 APIs could sit on cleanly. While a good idea, it quickly broke down in implementation. I ended up writing code that straddled the Nucleus and the Linux/OS X APIs, rather than abstracting everything away. This led to slower development and an even more complicated code base.
Potential new design
Having done two implementations of Alky and quite a few other projects that relate to it in concept (IronBabel, Renraku (OS design plays a factor here), etc), I think I'm at a place where I can perhaps come up with a workable design.
The key point where both Alky implementations (and Wine, IMHO) failed is in maintainability. The codebase was a rats nest, much like the real Win32 APIs, and neither implementation managed to help this at all. I think this needs to be the absolute top priority, above performance, compatibility, and all else. If your code is maintainable, all the rest can happen.
With that focus in mind, here are the things I'd do with a new design.
- Implement the APIs on top of Mono, taking advantage of the flexible marshalling that P/Invoke gives you. This will allow you to simplify things greatly, and will only have a marginal performance hit in most cases.
- In cases where performance is critical, drop down and implement things in C, C++, or assembly. If this chunk of the project is greater than 10% of the codebase, you've got bigger problems.
- Abstract, abstract, abstract. Break things into the smallest chunks possible and reuse them. This is what we tried to do with the Nucleus idea, but it was easy to just ignore it for complex pieces.
- Write thorough unit tests for every API that's implemented (public and internal). Regression testing would also make things really nice.
- Rather than trying to get real games/applications running immediately, write your own simple applications that test specific chunks. This would've cut down considerably on the development time in the old revisions of Alky.
- Write a great debugger to be able to step through applications cleanly. In the old days, I'd break out IDA Pro and step through a game on Windows, then compare the behavior to the Alkified version, but this was just downright painful.
- Make it work on Windows, to allow easy side-by-side comparisons.
The suggestion that this should be built on top of Mono/.NET sounds ridiculous, I'm sure, but I do think it'd give the project a shot.
In Closing
I hope this has given you some insight into what went down with Falling Leaf, some ideas of what not to do (obviously, it's easy to completely overlook these things when you're down in the trenches, as we did), and where Alky could one day go. I wish the Alky Reborn folks the best of luck, and I hope some of my advice helps.
Happy Hacking,
- Cody Brocious (Daeken)
Direct links:
0 - This is impossible, it simply can't work from a technical point of view. (This was especially hilarious coming from a Transitive engineer, considering that what they did is considerably more complicated.)
-
-Multi language suport (Russian, Spanish, Polish, english and Portuguese).
-XP Shell Icons - (Replace shell32.dll and explorer.exe icons)
Italian, please, and Tango XP (or Crystal Clear) would be great.
0 -
-
I'm noticing problems in a/v synchronizations under XP 64.
Can be an HPET problem ? Or, in other words, does XP 64 supports it ?
Thanks in advice !
0 -
FullFAT 1.0.0 (RTM) Released
FullFAT 1.0.0 has now gone through a large amount of testing, and is now considered stable.
A new 1.0.0 (FINAL) release will be available in the coming weeks. This will contain the same source code (unless any major bugs are found) however will contain extra drivers, updated demo's for linux, etc etc. As well as a complete stdio integration demo.
New features:
* FF_Move() (rename) API added.
* Deleting now removes LFNs.
* Some minor bug-fixes and code cleanups.
Note:
Please format any media that was used with earlier versions of FullFAT. Earlier versions didn't delete LFN entries, and therefore left orphan LFN entries. This when renaming a file with 1.0.0 this can appear as a bug. However 1.0.0 is not broken, its just that the directory is corrupt from earlier versions.
0 -
http://www.systemax.jp/en/sai/
SAI or PaintTool SAI (ペイントツールSAI?) is a painting program for Microsoft Windows developed by SYSTEMAX.
Uhm, it would be great if someone "grabs" a package manager-like for serving KernelEx with 100% functional software (better if open source).
0 -
Hey, guyz, I opened a 3ad about VLC+KernelEx @ VideoLAN Forums:
http://forum.videolan.org/viewtopic.php?f=14&t=64425
Feedbacking is useful !
0 -
Also Mpeg2 decompression with cyberlink is very fast and i seems to be almost cpu independent when hardware acceleration is enabled.
True, VLC don't have mutch hardware optimizations integrated, but is still better 'cause don't install anything that overhead the system.
I prefer to use decoders which were used to encode the file. For better quality.You don't obtain better quality using the same codec but with a better one !
And note that FFDShow is FFMpeg based too...
0 -
Codecs and Media tools:
Media Player Classic:
The one i can mostly reccomend. Has some internal filters, usable to play audio and video files, DVDs and can connect to Video Devices such as TV tuner, VIVO or Digital camera. Also can play videos using Overlay mixer, Video Mixing renderer 9 and Haali renderer. Shader effect...
Windows Media player 9
Few months ago i was solving problem with WMV files - they were always choppy when using any player. The only way how to fix it was to install WMP9... Also this is only player able to play Digital Audio CD input through SPDIF which is connected directly from CD/DVD drive directly to SoundCard. The support of this feature is bit buggy but it is the best way how to play CDs. I dont recommend this software, but from my point of view it may cause trouble to work without it.
ATV2000 (latest)
Best software for Analog TV tuner viewing. Bit hard to control it but it has better image quality as many other software. Widely localized. Allows realtime capturing and encoding software and for some cards hardware MPEG.
ProgDVB 4.85.3
Best software for Digital TV tuner. Look at previous post for details. Allows recording in MPEG2 Stream format. When you fix the codecs it is very usable without any bad errors.
Power DVD 6
It is commonly bundled with DVD drives and graphic cards and in some cases with a legal CD-Key. Player itself is not interesting, but it contains a lot of usable codecs which are one of the best for Mpeg2 decoding. CLVSD.AX can decode mpeg using hardware acceleration which makec CPU load lower. Version 6 works correcly witn ProgDVB and MPC.
AC3 Filter 1.63a (latest)
The newest version of this sound decoder also contain very usable Equalizer which can really improve sound quality from DVDs, Digital television or other sound sources. This build is localized in many languages. Not so User friendly, but offers many possibilities in setting good sound quality. (ac3, dts, mpeg, pcm, ... and others)
Note: When using AC3 filter with equalizer in MPC and 5.1 sound, if video is choppy set in MPC "Default sound device". I had some trouble when it was set to "Direct sound device:SoundBlaster LIVE". Correct setting for me was "Soundblaster LIVE" althougt it seemed same for many other videos it is not.
Direct VobSub 2.23
Not the newest. Newer versions caused trouble with YUY2 colorspace while playing Xvid videos. I have to check if there are other versions. If you try to play video in VMR9 with subtitles YUY2 and YU12 formats are impossible to set, default colorspace is always RGB32. That setting is quite CPU consuming, but it may be connected with the video which was used to test. Newer versions were able to use YUV2, but the image was crippled and "Mod32 fix" didnt worked.
Xvid - Koepis Build (Latest)
Officially not supporting Win9x but it works great. Still under development. I recommend it for all Xvid and DivX videos.
FFDShow
Support for windows 9x was dropped. have to find last stable release for them. Usage: good for decompressing of formats you dont use commonly.
H264 VFW
Quite good h264 decoder, have to find its details
Virtual DUB
freeware. good working. i have to find some details about it.
this page will be edited within day or two. i want to add here all links and re-test some things. I dont reccomend to use any of Codec packs available on web. Most of them are not correctly set.
Beware of Nero - might screw up all codec settings.
...if you need to kill your Windows 9X/ME performances.
If not, choose VideoLAN instead.
0 -
I have been stunned when i realized that whole Vista is programmed in .net C#
.net C#. that makes vista bit more efficient
If doubt that's true, but If so I (and probably Bill too, that's why he leaved) can understand now why Vista and 7 completely sucks.
0
[WIP] Windows Vista Extended Kernel
in Windows Vista
Posted
Totally agree: a more strict collaboration with open source projects like ROS would benefit all.