Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
does anyone have an article how to do this ?
Since you gave no exact version of Visual Studio, let me give you the options I am aware of.
Visual Studio 2012, 2013 and 2015
Respective contemporary DDK/WDK versions: WDKs 8, 8.1 and 10 (as of this writing).
With the WDK for Windows 8, the WDK team at Microsoft finally offers full integration with Visual Studio again directly from Microsoft.
However, while Visual Studio 2017 exists in minor version 15.4 already by the time of this update, the WDK still requires Visual Studio 2015.
Visual Studio 2002 through 2010
Respective contemporary DDK/WDK versions: DDKs for Windows XP/2003 Server, WDKs for Windows Vista and Windows 7 with their respective service pack levels and the respective server versions.
Those versions were not officially supported by Microsoft to build drivers. The only worse choice to compile a driver would be a complete third-party toolchain (other than Intel's C compiler which was sanctioned by MS, IIRC).
It was considered very bad form to use the Visual Studio compilers during that period, and Microsoft explicitly recommended against it. However, C++ in kernel mode was also once frowned upon and now MS provides C++ frameworks for kernel mode. The times they are changin' ... ;)
Anyway, workarounds exist in the form of ddkbuild.bat and ddkbuild.cmd which use the DDK toolchain, but effectively allow you to integrate the resulting invocation from your "make" project inside Visual Studio. DDKWizard is a project creation wizard for both of those scripts. DDKWizard does not support Visual Studio 2010! The links to the two scripts provide a good documentation and DDKWizard also comes with a decent documentation.
To my knowledge ddkbuild.cmd is originally based on ddkbuild.bat and the HollisTech version can also trace its heritage back to that version from OSR.
VisualDDK combined with VirtualKD emerged later than the aforementioned, but is to be considered a far superior, more sophisticated solution. But your mileage may vary. In either case the integration into Visual Studio is far more complete in the latter solution.
Visual Studio 6
Respective contemporary DDK/WDK versions: DDKs for Windows NT 4 and Windows 2000.
Prior to the Windows XP DDK (now DDK is called WDK) the compiler was not included in the DDK, so you had to have the compiler toolchain installed. This would be the case for NT 4.0 and Windows 2000.
Download and install VisualDDK and you'll be able to create driver projects and debug drivers directly from Visual Studio.
The ddkbuild from OSR-Online is a nice alternative ddkbuild download link.
To build my driver i used VisualDDK in visual studio 2008. In the beginning i start debugging using my computer and virtualBox machine but when i launch the debugging process in visual studio, my virtual machine did not show me the external ip address(normally should show me 192.168.1.102 and 10.0.1.15 in DDKLauncherMonitor but it show me only 10.0.1.15 ).
I stopped using virtual machine and i decide to use real computer. In the second computer i launched DDKLauncherMonitor. And i start debugging from my first computer. I received Udp package in my second machine and also the driver.sys. But when i tried to load the driver from visual studio(First computer) nothing work. Plus this, in the second machine tell me "Windows required digitally signed driver".
There is same one meet this kind of problem and he/she can help.
create a makefile project and use the following as the build command:
pushd .
call C:\WinDDK\7600.16385.1\bin\setenv.bat C:\WinDDK\7600.16385.1\ chk x86 WXP no_oacr
popd
build -cgwiz
(obviously tweak the arguments to setenv to suit)
If you want to use DDK build and WDK use ddkbuild.bat, it is pretty good (I think most of it works still) that should have you going. Alternatively check out ddkbuild.cmd from OSR.
In VS create a makefile project. Add your sources, headers, makefile and sourcefile. Open project properties->Configuration properties->NMake->Build Command Line and write:
call $(WINDDK)\bin\setenv.bat $(WINDDK) fre wnet
cd /d $(ProjectDir)
build.exe -I
Now you can build from VS. The advantage of the makefile project: it provides you with as many configurations as you need (w2k, wxp, wnet, wlh and etc) and you can build from the DDK command line.
P.S.
fre wnet - is a sample configuration, use what is required for your project. It is good to have both fre and chk configurations.
WINDDK - environment variable with a path to the DDK root.
Related
I'm following the instructions in
https://msdn.microsoft.com/en-us/library/office/hh361572(v=office.14).aspx but after installing the runtime, the voice, and the SDK, I couldn't figure out how to reference the Microsoft.Speech.Synthesis namespace on my Windows 7-64 bit machine with Visual Studio 2013 community edition update 4.
What's the real purpose of the SDK and how do I configure.
The installers are 64bit versions, and the voice synthesis works
PS: If you really think that my question is unappropriate here, please just put it in the comments or answers and suggest me where should I put it. I'll b glad move it far from your judgement in less than 10 hours
I believe you need to use C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\System.Speech.dll (for whichever .NET version is appropriate). It is a wrapper around Microsoft.Speech.dll. I was having problems selecting the voice, but it turned out to be just build configuration.
I want to write some simple code using DDK - but i don't know even how to compile some demo code that i download.
How to compile this thing ?
Is there some simple editor / IDE that i can use ?
Is there some way to use visual studio to write and compile DDK ?
Generally the WDK consists of a command-line tools. No IDE or etc. However with some efforts it's possible to setup the MS standard IDE (MSVC2005/2008/2010).
First download and install the latest WDK package (from the official MS website). Go into
StartMenu -> Windows Driver Kits -> WDK xxxx.xxxx.x -> Build Environments.
There you'll find a list of build environments. Each one is just a shortcut to cmd.exe, with plenty of environmental variables set accordingly. Those are build environments for different Windows version, plus for each you have a free/checked configurations, which is equivalent to user-mode's Release/Debug builds.
In order to build the driver you should launch one of those shortcuts. Then, in the command prompt, go into the source code's directory and run build batch command. The rest is determined by the makefile residing in the selected directory.
It is possible nevertheless to use the standard IDE for driver development. That is, use vcproj (or vcxproj in MSVC2010) instead of makefile. This however requires setting many build parameters.
Currently there are two main paths to choose from:
1. For drivers running on Windows 7 and above:
Since Visual Studio 2013, you can use Visual Studio's built-in integration for working with WDK projects, which is a full blown IDE for driver development.
Sample screenshot from Visual Studio 2015 + WDK 10:
There is also a short guide from Microsoft on what one needs to get started. The guide includes links to downloads of Visual Studio, WDK and samples - Get started with Windows 10, Visual Studio, and the WDK:
Used together, Visual Studio 2015 and WDK 10 provide an integrated
development environment for creating efficient, high-quality drivers
for devices running Windows 10. This release of Visual Studio includes
the Visual Studio Tools for Windows 10 and the Microsoft Windows
Software Development Kit (SDK) for Windows 10.
In short you need to install Visual Studio 2015 with Update 1 and WDK 10. Your OS need to be Windows 7 or newer (desktop only, not server).
2. For drivers running on Windows XP:
If you need to stick with older WDK 7.1 (eg. for Windows XP support), then this guide from Donald D. Burn can be a good start - Getting Started with Windows Driver Development:
WDK MVP Donald D. Burn shares his experience and insights about tools
for creating a device driver for Microsoft Windows, with information
about debugging, testing tools, and techniques that can help you find
and fix bugs early in development.
...
Updated with changes to the tools, build environment, and best
practices from the Windows Server 2003 Service Pack 1 Windows Driver
Kit (WDK) to the Windows Driver Kit (WDK) Version 7.1.
Choosing this path usually requires compiling drivers in command line via Build Environments, as described by valdo's answer. As for coding you can use an editor of your choice.
I'm using msscript.ocx in my application which is an activex scripting host for windows.
Although I want to be able to use the same for XP embedded(XPe) which's highly customizable.
1.I want to know whether on XPe, msscript.ocx can be optionally installed or not?
2.Where does it get installed from, IE?
3.Or is it a windows core component which gets installed during the XPe setup?(I know one can unregister it, but can it be an optional installation)
Answering any or all of these questions will be of great help to me.
Thanks in advance.
Sam.
Microsoft's documentation of the MSScript.ocx library is somewhat contradictory on this issue. The short answer is, starting with Windows 2000, the MSScript.ocx library became part of the Windows OS. Subsequent service packs for Windows 2000, XP, and 2003 included bug fixes (1,2,3) for this library. Since that time, the library has remained part of the 32bit portion of Windows and is still included with Windows 7/2008 R2. Even 64bit versions of Windows still include msscript.ocx with WOW64 in C:\Windows\SysWOW64.
For a little history of this library's distribution keep reading.
Msscript.ocx was originally included on the Visual Studio 6 CD as a "optional" library - optional meaning it had to be manually installed. While the library was part of Visual Studio, it was migrated to being part of the Windows OS starting with Windows 2000.
This is where the confusion comes into play. Since msscript.ocx is considered to be a component of both VS6 and Windows 2000, updates were distributed in service packs for both. Even after the last service pack for VS6 was released, additional bug fixes needed to be distributed for older OS's, so a separate download was created specifically targeting Windows 95, 98 and NT4.
This download is targeted for older OS's for the simple fact that it had become a part of the OS in "modern" versions of Windows. If you are using Windows 2000 or greater, the download is unnecessary and - in my experience - can cause compatibility problems.
I think it is not shipped with Windows XP(not a 100% sure)...
But the best choice is to ship it with your installer(even if it was shipped, it can be removed). About the installing - you can put it where you want (in the program folder in Program Files is ok), the important thing is to register it.
The best choice for making installers - Wix
EDIT: reference
The Script control ships with Visual
Basic 6.0; however, Visual Basic 6.0
setup does not install the Script
Control for you. The control is
located in the CD directory
Common\Tools\VB\Script. To install the
script control, try the following
steps:
I think this answers your question....
For those having issues getting MSSCRIPT.OCX to work do the following:
Go to References in Project settings:
Microsoft Script Control 1.0
Microsoft Scripting Runtime
Microsoft Scriptlet Library
Check all those on.
you'llneed to change your development environment to produce a 32 bit version of your appliation, which for most apps won't matter.
For this goto Project,
then select Properties,
select Compile,
Target CPU: x86
In your code, and i'm using visual studio 2019,
' by using the references above the ScriptControl
' should become available for inclusion into your source c
Dim ms As ScriptControl = New ScriptControl
ms.Language = "JavaScript"
ms.Reset()
Try
ms.ExecuteStatement(RichTextBox1.Text)
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
I've downloaded a Vista icon from the web for a new application I'm developing. When I try to compile it in Visual Studio 2005 C++, I get an error message:
error RC2176 : old DIB in res\XXXXX.ico; pass it through SDKPAINT
The error message seems a little misleading, I think the "old DIB" is actually a newer format that it wasn't expecting. I've never heard of SDKPAINT, and Search doesn't find it installed on my system anywhere. Microsoft claims SDKPAINT comes with the Windows 3.0 SDK, but I can't download any SDK due to incompatibilities with our firewall.
I don't really need anything Vista specific in this icon, so anything that would dump the incompatible bits would be fine.
I did a little more digging, and I found this previous question:
Which Icon Editing Software would you recommend for creating icons for apps
The accepted answer for that question suggested IcoFX. I downloaded that and used it to delete the 256x256 and 128x128 versions of the icon, and now everything's fine.
There are two more ways to achieve this in Visual Studio 2005:
replace rc.exe and rcdll.exe of your Visual Studio 2005 installation with the ones from a newer SDK (e.g. Windows Vista, 7 ...) or DDK/WDK (ditto)
or integrate the newer SDK into your Visual Studio 2005 using the respective tool that comes with the SDK
The resource compiler is the part that creates the .res files and then the usual Visual Studio 2005 linker (with the first option) or the SDK tool chain's liner links that into the binary. Meaning that even in conservative scenarios where it is frowned upon to upgrade the tool chain as a whole, this should be harmless.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last year.
Improve this question
I started trying to play with Mono, mostly for fun at the moment. I first tried to use the Visual Studio plugin that will convert a csproj into a makefile, but there seemed to be no version available for Visual Studio 2005. I also read about the MonoDevelop IDE, which sounded nice. Unfortunately, there's no pre-fab Windows package for it. I tried to follow some instructions to build it by combining dependencies from other semi-related installs. It didn't work, but that's probably because I'm a Windows-oriented guy and can barely spell "makefile".
So, my question is this: What's the lowest-energy way to get up and running to try some Mono-based development on Windows?
I'd recommend getting VMWare Player and using the free Mono development platform image that is provided on the website.
Download Mono
Setup time for this will be minimal, and it will also allow you to get your code working in .NET and then focus on porting issues without a massive hassle of switching machines and the like. the VMWare Player tools will allow you to simply drag and drop the files over to copy them.
I'm looking to take a couple of my .NET apps and make them Mono compliant, and this is the path I'm going to take here shortly.
A year later and the answer to this has change greatly. You can now use MonoDevelop on Windows, or if you are more comfortable in Visual Studio you can use the Visual Studio Tools to write everything and then debug on in VM to make sure it is working on Linux.
#Chris I have found that Visual Studio is the best IDE for developing against .NET -- I think the best way to target Mono is really just to develop and build in Visual Studio under Windows then just run those binaries directly on Linux (or whatever other Mono platform you are using). There are free versions of Visual Studio if licensing is a concern. If you are developing under Linux, the best software is probably Eclipse with a Mono plugin (see The Mono Handbook - Eclipse for installation instructions) but keep in mind it doesn't have near the amount of features or language integration Visual Studio has.
#modesty Mono is a 3rd party open source implementation of the .NET framework which allows you to run .NET applications on platforms other than Windows.
One of the best things you can do if developing with Visual Studio for Mono is to get MoMA http://www.mono-project.com/MoMA. This will inspect any number of assemblies that you build and generate a report showing potential Mono problems (e.g., methods not implemented in the mono library). It can be run from a GUI or the command line for use in automated builds.
Miguel had a post about debugging Mono running on linux with remote debugging on Visual Studio. This may be something you want to look into... Using Visual Studio to debug Mono. There is also a new project called CloverLeaf whose goal is enabling debugging Mono on Windows in Visual Studio.
There's just no reason to build your app using Mono; the whole point of the .Net CLR is that the compiled output is cross-platform.
So you can simply build it using your favourite IDE (and if you like IDEs, Microsoft's is the best one to use) and then test it on Mono. Even if you get Mono working on Windows, it wouldn't be a very good test of your app's portability: what if your app does silly things like assuming filenames have backslashes in them, or that there's something special about a folder called Program Files? The best way to do portability testing is to actually test your app on the target platform.
And that's pretty easy to do with a Linux VMware player like the one at http://www.go-mono.com/mono-downloads/download.html.
Personally, I'm just compiling in Visual Studio 2008 as if it were for .Net 2.0 and then running in Mono (VS2008 on Windows in a VirtualBox, Mono on OSX). All the problems come up at runtime, anyway, so the system works perfectly.
I just found this very new link, which is amazing and shows you how to set up Visual Studio 2008 for Mono.
At the same time, setting up Mono on OpenSuse or Ubuntu inside a VirtualBox (Sun's product) is easy, painless, and doesn't force you to abandon whatever platform you normally live in.
This is not relevant to your question, but I might note that I just got into Mono and I'm amazed at how much of .Net is implemented, including much of the Winforms stuff.
My first instinct would be the rather unhelpful "Install Linux". You are somewhat swimming against the current to try and develop in mono under windows. Installing GTK and everything is a bit of a bother in my experience.
If you do feel like using linux, then you could Try Ubuntu
Otherwise:
There's some information here: http://www.mono-project.com/Mono:Windows and it seems the cygwin toolchain might be your best bet. I don't think you're going to be able to avoid makefiles, sadly. I found a slightly more explicit tutorial from O'Reilly.
#modesty: Mono provides the necessary software to develop and run .NET client and server applications on Linux, Solaris, Mac OS X, Windows, and Unix. Sponsored by Novell (http://www.novell.com), the Mono open source project has an active and enthusiastic contributing community and is positioned to become the leading choice for development of Linux applications. -- From the Mono site.
Eclipse plugin for Mono is dead. On Linux use MonoDevelop or X-Develop if you like good commercial support (although MonoDevelop is closing on them fast feature-wise). On Windows SharpDevelop has custom MSBuild targets for compiling the code against Mono.
As Mono and MonoDevelop are changing fast, be sure to use the latest released versions, even if they are not marked as stable yet (e.g. versions shipped with stock Ubuntu are terribly outdated).
The VMWare image is a great way to start testing Windows-developed code on Linux. Don't touch cygwin unless you are already very conformable with it.
I liked the idea of trying to use MonoDevelop mostly just to make sure my stuff would work against the Mono runtimes. I guess it would also be possible to get crazy with msbuild and write some custom targets that tried to build against Mono, but that's basically emulating the now-defunct plug-in's functionality which I assume was non-trivial to build. I do have minor experience with cygwin, and I am happy typing "configure" and "make" all day long, but when a problem occurs in that process, I'm virtually screwed. I'll probably try to play with all this again, but if it takes me more than a couple hours to come up with a way to build comfortably against the Mono runtimes, I'll probably just bail.
I will try the Eclipse idea. I use that for Java, so I might be able to get the c# stuff to work. We shall see...