NypyrenMember Since 19 Aug 2002
Offline Last Active Yesterday, 10:27 PM
- Group Crossbones+
- Active Posts 3,587
- Profile Views 6,620
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Eugene, OR, USA
C#, F#, x86-64, Developer Tools
Posted by Nypyren on 29 July 2014 - 07:41 PM
Things to try:
- Delete your project/obj folder (and project/bin, if it exists). These folders are where VS puts its Intellisense databases and should be deleted in addition to the SUO file. Since you're using Unity, it's unlikely that the folders contain any other important data, but on a normal VS project, you may have other files in these folders that you DON'T want to delete. The important ones to delete are the .idb, .pdb, and .cache files.
- If using source control, sync to an older revision that you remember working.
- If you have any VS plugins installed (especially Intellisense related), try temporarily uninstalling them.
- Make sure Unity doesn't detect any compile errors, then delete the .sln and .vcproj files and regenerate them by double clicking a source code file from inside Unity.
- Unity creates two different SLN files. Try both of them to see if the problem is the same on both.
- If all else fails, you can also delete your project/Library and project/Temp folders. These usually don't cause Intellisense problems, though.
Posted by Nypyren on 29 July 2014 - 01:42 PM
Long answer: Instead of saving a pointer, save information that lets you recreate the desired data structure or find the existing data structure if you expect it to already be somewhere in RAM. For example, you might give each type a unique ID followed by data which lets you call a particular constructor, factory method, search through an existing object list, etc. This process is called serialization/deserialization and can be easy or complicated, depending on how flexible your format needs to be - you should do some Google investigation about what serialization is to get some ideas on how you could apply it to your situation.
I'm not intimately familiar with DX11, so I'm just going off of what I googled just now. Here's what I would do:
- Write information that lets you create or find the ID3D11Resource* that you will need for the first parameter to CreateShaderResourceView. I am not familiar with DX11 so you'll have to figure out how you want to do this on your own.
- Write the SRV's D3D11_SHADER_RESOURCE_VIEW_DESC contents to the stream. This struct appears to be a POD (plain old data - in other words, a single contiguous block of data with no pointers to anything else), so this should work. You can save this in the manner you're using above.
- Load the information that lets you create or find the ID3D11Resource* you need.
- Load the D3D11_SHADER_RESOURCE_VIEW_DESC from the stream.
- Call ID3D11Device::CreateShaderResourceView using those two pieces of information. This will give you the interface pointer to the newly constructed resource.
Alternatively, if your code works by creating a bunch of ShaderResourceViews in memory and you aren't using the stream itself to construct them, you can simply save/load a unique ID which allows you to find the existing ShaderResourceView object which already exists in memory. Though you can't use a pointer, you may be able to use an array index, GUID, or string for this.
Posted by Nypyren on 27 July 2014 - 05:37 PM
The entire first page answered every possible interpretation of your question, EVEN AFTER YOU CHANGED IT. At this point, perhaps you're just trolling?
Posted by Nypyren on 23 July 2014 - 08:48 PM
There are tools like DependencyWalker ( http://www.dependencywalker.com/ ) which can analyze the dependencies. Try investigating that to see if there's anything else unexpectedly missing.
Posted by Nypyren on 16 July 2014 - 02:03 PM
B) From what SmkViper says, it sounds like I can't make a 64 bit program recognize a 32 bit DLL. That can't be right though, because what if I need a program to be 64 bit, but use a 32 bit DLL? Or what if I need a program to use 2 different DLLs and one is 64 bit and the other is 32 bit and I can't recompile them because I don't have the source? There would have to be a way to do this.
64-bit processes can't load 32-bit DLLs, and vice versa. All EXEs/DLLs loaded into the process must match.
The exception is that .Net's "Any CPU" DLLs can be loaded into 64-bit or 32-bit processes because the JIT can generate the appropriate code either way.
.Net's "Any CPU" EXEs, on the other hand, will start a 64-bit process if your OS is 64-bit, or a 32-bit process if the OS is 32-bit, but any DLLs loaded thereafter have to match the bit size the EXE picked.
If you don't have proper versions of all DLLs and don't have the source code, you have to go with the bitness that you have available (32-bit, in most cases). When making a .Net EXE which loads 32-bit DLLs, you have to make sure to change the .Net projects to target x86 instead of "Any CPU".
Posted by Nypyren on 11 July 2014 - 07:16 PM
Wonder if all privs here are just some mallocks 1-1
They're not 1-to-1, otherwise you'd have very inefficient use of RAM. For example if you allocated two blocks of 16 bytes apiece, they will probably go in the same Priv page. You wouldn't want to have a separate 4K priv page for each one.
Can you say yet what you mean by many heaps? each such heap is in different wirtual space or those heaps lays in one wirtual space but are defined over some distinct blocks, or what? tnx for info, if i find some more info i cand extend this picture yet in some details, very interesting things, much usefull for some kind of things (like taking care whats going on)
It's implementation dependent (it's up to the memory manager). For example, the .Net Large Object Heap probably puts its pages in a different area than the generational heap(s) to avoid fragmentation on the LOH from impacting the generational heap. The MSVCRT heap can also do the same kind of thing. You'll likely see completely different memory management schemes between different vendors.
Posted by Nypyren on 10 July 2014 - 05:39 PM
system dlls seem to not have .bss sections (it seemed strange for me but maybe they are written such way - mallocs instead bss)
If the uninitialized data is small, the compiler might decide to include it in the initialized data section instead.
stack seem to have 16 kb only but there is adress space for potential 2 MB
The stack overflow handling behavior can expand the stack on the fly (if it's set up to do so) and resume execution gracefully if the stack was expanded safely.
1. those "Map" blocks still confuse me, there ara about 20 of them mostly small, most seem to be data (some read some radwrite) but some are executable (and mysterious - not described)
do such memory mapped meand more like real disk file that is mapped or this is more like shared physical ram blocks ? are those really disk files? this is confucing - maybe someone is able to clear it a bit
I haven't personally used memory mapped files more than once. I believe you can use them to share data between two processes with or without "real" disk files, but I've never actually tried that.
2. thise privs also confuse me yet - i wonder if those are just mallocked buffers - sad there is no description (if so) which module mallocked them
(i mean if loaded dll's if some loader external to those dlls (like stack was probably allocked by some loader or what) or my prog
I could probably make same experiment by logging my mallocks adresses and comparing them to such blocks.
maybe those privs together make juz a mallocked heap? if someone could add something to this picture it would be fine
ps. some privs here are marked executable but as this is moderately simple winapi app there should be no jitted or injected code.. so i dont know how to explain this
"Priv" probably stands for "Private bytes" (which is what a few process memory reporting tools on Windows call a process' memory usage).
As far as I know, here's how it works:
- VirtualAlloc is what allocates the pages you see in your screenshot, and VirtualProtect sets their flags. However, a heap implementation is free to make as many different page allocations as it wants to, even if they are not all in one block of contiguous address space. Since page sizes are a fixed size (usually 4096 bytes for a typical 32-bit Windows process), there may be some unused space in them that the runtime library's memory manager hasn't specifically made part of its heap yet.
The different DLLs in your process are free to share a heap, or use multiple separate heaps as well. They avoid overlapping with each other because VirtualAlloc won't let you allocate pages which are already allocated.
As far as your unknown Priv+execute pages go, any third-party applications on your computer may install system hooks which cause DLLs to be loaded into your processes even if they aren't normally part of your program. Mice and keyboard vendors, for example, may with software that will load various DLLs into (nearly) every process in order to handle special shortcut keys or gestures. It might also be something Olly is doing (I haven't used Olly - I have my own tool to show the same kinds of information, except I know for certain that it does not inject anything).
Posted by Nypyren on 10 July 2014 - 12:07 PM
I guess .reloc could probably be reclaimed - I don't think an image (exe/dll) will be moved again after it's loaded. Though I've never seen a process reclaim .reloc pages for other purposes yet.
As far as I can tell from the picture, "Map" stands for memory-mapped-file. Memory mapped files are an operating system feature that let you map a file or a portion of a file directly to memory - reads and writes to the memory will impact the file without having to fread/fwrite/etc.
All of the other stuff (marked as "Priv") are anything the process has allocated dynamically. These could be heaps, stacks, JITted code (if you see any pages outside of the image regions that are marked as execute, it's JITted or injected code), or whatever else the program was written to allocate. It depends on the program (which language, runtime library, manual memory management, etc it uses).
The BSS pages in your picture are expanded in the middle of the image pages by the loader. They are fixed in that position because the executable was built to expect them at that location.
The pages marked as "RW Guard" are guard pages used to detect stack overflows by triggering a special exception if they are accessed.
Posted by Nypyren on 08 July 2014 - 06:58 PM
alright, could you answer me if the code generated in raw bin (seen as this jpeg picture) is 16 bit code or what? or is this 32 bit code to run in 16 bit mode? why nasm generated it such way? it would be strange if it would generate code that purpose is tu crash anywhere.. and if not crashing would it be able to really run sse code in 16bit mode or something ? (sorry if the questions is a bit indepth, but maybe someone will know this)
ps when disasembly it was bring
c:\asm>ndisasm -b32 -o40001000h -a tezt.bin
40001000 66678B5424 mov dx,[si+0x24]
40001005 0466 add al,0x66
40001007 678B4C24 mov ecx,[si+0x24]
4000100B 080F or [edi],cl
4000100D 57 push edi
4000100E C067F30F shl byte [edi-0xd],byte 0xf
40001012 7F02 jg 0x40001016
40001014 6683C210 add dx,byte +0x10
40001018 6683E910 sub cx,byte +0x10
4000101C 7FF1 jg 0x4000100f
4000101E C3 ret
extremally wrong maybe i should try -b16
c:\asm>ndisasm -b16 -o40001000h -a tezt.bin
40001000 66678B542404 mov edx,[dword esp+0x4]
40001006 66678B4C2408 mov ecx,[dword esp+0x8]
4000100C 0F57C0 xorps xmm0,xmm0
4000100F 67F30F7F02 movdqu [edx],xmm0
40001014 6683C210 add edx,byte +0x10
40001018 6683E910 sub ecx,byte +0x10
4000101C 7FF1 jg 0x100f
4000101E C3 ret
seem okay but do such hex is able to run on 32 windows?
some flag i think must be setted somewhere to treat this as
some 32-16 mode (as i suspect this is 32 bit code but with some
16 bit args by default)
probably this explains most of the think - i need to find some flag
to denay this 16 bit default
Exactly - the behavior depends on BOTH the CPU's mode for the process (16-bit, 32-bit, or 64-bit are the ones that x86-64 processors support currently) AND the prefix of the instruction. Your encodings were built to be executed in 16-bit mode (this is why the 32-bit operands got assembled with 66 and 67 prefixes). Microsoft PE files (EXEs and DLLs) have field(s) in the headers which specifies which processor and mode the code should be executed in.
Current Windows programs should always target either 32-bit or 64-bit modes, since 16-bit executables are no longer supported on 64-bit editions of Windows.
Posted by Nypyren on 08 July 2014 - 01:36 PM
The 66 prefix is used in some SIMD encodings. MOVDQA and XORPD use it though, not MOVDQU or XORPS.
It is also used with other general purpose instructions to override the operand size (on 32-bit and 64-bit mode, it switches to 16-bit operand size, and in 16-bit mode it switches to 32-bit operand size)
67, on the other hand, when used in a 64-bit process, allows you to select 32-bit address size in certain situations which may be useful.
Encoding 8B: MOV Gv, Ev; both Gv and Ev respect the operandSize override. Since you're using a memory form of Ev, it also respects addressSize override. In this case you must remove the prefixes since it will cause the encoding 66 67 8B 54 24 to become "mov dx, word [Si+0x24]" instead, causing another catastrophic problem: your 04 will no longer be part of the instruction, and will be decoded as its own instruction. At that point your program will likely catastrophically fail since you've "derailed" the instruction pointer.
They are not obsolete, but if you use them wrong, it will cause undesirable results like Spiro said.
Posted by Nypyren on 25 June 2014 - 11:07 AM
If people in general knew how web applications are often written, nobody would dare use the internet.
If people could see all of the code I've seen in the past 20 years, nobody would dare use desktop apps, mobile devices, or consoles, either ;)
(But yeah, web applications are by far the worst)
Posted by Nypyren on 14 June 2014 - 01:32 AM
Also, if you quit, make sure to give a couple week's notice (or whatever's required by law, if you have a law which covers this). I quit one of my summer jobs at a grocery chain once without notice and they blacklisted me from ever working there again.
Posted by Nypyren on 14 June 2014 - 01:23 AM
- Shell scripts doing ANYTHING mission critical: check.
- Functions more than a page long: check.
- Codebase existing more than 10 years: check.
"I'm sorry, I'm afraid the cancer has spread throughout its entire body. There's nothing we can do for it anymore." - Doctor Nypyren
Why not look for a new job while you're still employed and bail out the moment you find one?
Posted by Nypyren on 12 June 2014 - 06:10 PM
Binary literals will be more useful for multiple bits, I suspect.
Posted by Nypyren on 16 May 2014 - 12:32 AM
I tried both the OtherContextMenus.SmartTag.Rename command (the one you used in your screenshot) and the Refactor.Rename command (Ctrl+R+R or right-click -> refactor -> rename) and both worked.
Is your file read-only? Does it have any lingering compile errors? Is your project using source control? Are you currently debugging the program? Are you currently editing a file which is not actually part of your project?